Git, Current Job Market and Doom in the Terminal ft. ThePrimeagen | Backend Banter 054 

Hey Lane, I'm a new graduate who was feeling pretty dispirited the last few weeks while trying to find a job. Your videos have really helped motivate me and put me on the right path to enjoy making projects and doing some leetcode in the meantime. Thanks for all you do!

Before using git, I had a script that automatically zipped my current project on Windows startup. The zip file was named after the current day and time. I regularly uploaded those zip files to an FTP server (manually) and actually never lost any data by accident.

5:25 I add files one by one while commiting. I have two reasons: 1. I code review my past self, check if i forgot something etc. 2. I formulate the commit message by going over the changes

10:30 this frustrates the hell out of me, when it comes to Masters programs... I want to study computer science, yet the degrees want to insist that I learn software engineering patterns and cloud computing - likely to help pad the schools' job placement stats. When I asked if I could replace those courses with additional algo/compilter/OS/theory courses, they said "no" :/

I had attended Prime's git session on frontend masters... And now I can say that I know git.. atleast I know the part of git that is often used in production, that part which most people fail to understand and perform big oopsies here and there.. thanks Prime❤️

On the other hand when I've worked at places hiring fresh-out-of-college devs, the fact that the colleges teach a lot of useless information but couldn't even be bothered to expose students to git was infuriating. Because _consistently_ I'd have to spend 70% of their onboarding time walking them through "okay, first you have to git add, then- no you have to type git add- no you can't do a commit yet because you have to stage things first... Yeah git _is_ really useful I have _no idea_ why your teachers didn't tell you about it :eye-twitches:" These kids aren't even _at_ the starting line half the time.

In my university, there's a mandatory software class for electrical engineering where students learn about linux programming and they also learn about git, valgrynd etc. This semester we started teaching devcontainers too, though only at a very basic level.

It's crazy to me that trade schools seemingly aren't more prominent in the IT field in the USA. Where I live, they've been well regarded since well before I was born.

"git add -i" gives a helpful interactive loop, and even lets you drill down and choose specific diffs within files to include or exclude from the add.

Starting from 28:00 Is it not already possible to use squash commits on merge without using rebase? One only needs to resolve the merge conflicts once per merge into their feature branch. This points toward the norms around your team's contributions. If you're releasing with branches, developing branches off of other branches, maintaining a feature for a long time outside the main, rebase makes more sense. It's less necessary for trunk based development.

In Germany, we have the concept of a University of Applied Sciences. You will also be able to do a Bachelor's or Master's but the goal is not to prepare you for academia, it is to prepare you for a career in the field. And often, professors are actual practitioners who do the teaching on the side. The degree also includes projects where you help a company with some practical problem.

Adding files individually is something I also don't understand, but I still don't just add everything. I love me some git add -p Interactively go through each bit that was changed and decide whether to add or not. This is great for double-checking your changes, make sure you didn't forget some debug prints, etc; and it also sometimes makes me realise that, actually, this should be two commits.

I remember huffman encoding from my algorithms class back in 1995, when we had to write a c program that compressed a text file by using that exact prio-Q algorithm.

I recall first version control. Sources on 64MB USB drive, once in the week we met with friends, we compared our new files with "repository" copied them over. If two of us had files modified in last week, we manually checked for conflicts. Then maybe in 2003 or 2004 we started using tortoisesvn.

24:39 I’m in the never merge camp. The only acceptable exception to that is when doing semi-linear history like what GitLab supports. I’m also in the never squash camp.

22:00 branch~1 would go back on the branch history. branch^1 would go back on the incoming merge history. Basically it chooses left or right path to trace back.

15:00 In Canada, we have 2 and 3 year programs. Confusingly for most people, we refer to those as College. We refer to bachelors, masters, and PhD courses exclusively as University to differentiate it. The 2 and 3 year courses are essentially vocational training, with much more emphasis on the practical side of things. If you take a third year, there's a lot more of the theory there. A computer programming course for example wouldn't introduce DSA and such until year 3 if you chose to take the 3 year program. An example of the sort of classes in a college course would be like a couple courses on Java, several classes on web development (one class is just intro to HTML/CSS and SUPER basic JS, next class would be mostly JS focused, maybe using React or some other framework), Classes on networking, digital logic/boolean algebra, basic stats, some embedded dev on an arduino or similar device, etc. The classes are broad, basic, and heavily focused on practical experience. They're generally much easier than the University/academia stuff. They're not as laser focused as a bootcamp, so students get a much broader introduction to programming. The 2 year programs I would consider not a great choice, since they really leave out all the useful comp-sci stuff, but someone who is a motivated self-learner could make do with it and self-learn all the comp-sci they need later. Many colleges also have co-op programs where they require students to take (paid!) internships for a semester per year, ensuring that students get real-world experience before even graduating.

15:08 I went to a school that genuinely did exactly that - a two year course with a singular focus of preparing you for the workforce. The school board consists of hiring mangers. To be on the board the company must also hire interns from the school. Students in the same vain are required to complete an internship to graduate. The internship can be with any company related to the degree.

The rule I have is rebase if you know how otherwise merge squash. Usually works out; if you really want to maintain your change history then you’d learn rebase by now, but most ppl don’t care they just want their code checked in.

I learned to not use "git add ." after adding 1000 meta file changes to a unity project during my first job. Also, another job had a build system that added unwanted local configs occasionally. So I think double checking isn't bad. Also, I also think going file by file helps remove any extra comments or unused code. Like a mini pr you do for your own code.

14:23 I wish I could do that for the subfields of computing science "only"

For the git in school, so far, whenever we have had team projects they would always tell you to use the school gitlab (for multiple reasons) (ok actually first year there was a full year project where they just said you can use whatever implementation of version control you want, which I didn't really like since they gave no info on what options you may want to pick and kinda just threw first years into the deep end, luckily I already knew git from using it personally and just told everyone how to use it, although we did some cursed stuff with it.) Anyway, we were directed on commands and a brief summary of different git flows and why you may use them and said that for that courses project you should try to implement a kinda github flow (it very much wasn't because they needed it to fit some marking schema, idk). It felt much better than the first year but a lot of the time just felt that there were still some stuff missing. But hey, schools are already doing some of the stuff Primeagen is saying, just maybe not enough.

Thought Prime was gonna lose me on his super spicy take, but he nailed it!

Add some "evil merges" in that Git training. Lol. Those are always fun.

9:40 that's how the free git book on the git website and the o reilly version goes about teaching git. really does help with learning git

The 6:15 "If I don't add it to the git ignore I'll accidentally add it at some point" comment is so accurate, but it's also why I prefer to manually review the changes to my files. If my typical process is to manually review my changes, I can work as quickly and as sloppily as I want to, without accidentally committing something silly, because I forgot to add a special step in my workflow. If my typical workflow is to catch mistakes by carefully reviewing all my commits, then I always have a backup plan for making sure I'm not mixing up WIP features with emergency production bugfixes. Due to the large legacy corporate codebases I'm usually working with, it's always a good idea to review your changes and make sure nothing unrelated is going out. It's also ironic that you described college as "getting bitten" at 15:40, only to go out on your own and learn, because that's exactly what I did. Literally. I had made plans to attend computer classes in high school that had been ruined multiple times. I had been absorbing concepts through osmosis, patiently waiting until I finally could enter a real computer science class. Only to have the Dean walk into our college class half way through the semester to explain that our professor "had an emergency", and wouldn't be returning. The last minute backfill they found literally just read word-for-word from the power point slides for the rest of the semester. All the students were pretty upset with how things went down. I was so fed up with being unable to find a real teacher that I decided I'd just teach myself. I went out, read the entire book from cover-to-cover, did more than half the exercises in the book on my own time, and I also learned the basics of C++ enough to build a small game. It truly was my teaching myself everything I'd need to succeed as a software developer. Hearing Prime talk about schools vs bootcamps actually makes me want to see how I can contribute to boot.dev.

19:20 I think that one null check 40 lines before is the correct way to go but it's sometimes good to have an assert() near the use site to trigger and error if somebody modifies the code above. The idea is that assert()s are active while developers are modifying the code but it's not needed to run in production version. And if developers are running with assert()s disabled, they should be shamed of themselves.

Berkeley EECS 61B teaches how to implement a Git client. We were already expected to know git use on our own.

I agree with Primes take on this wholeheartedly. A surface level understanding of git does not really provide enough workflow benefit over manual tracking of small personal projects. A deeper understanding would inherently 1) make it easier and understand 2) faster to use and 3) allow for more access to the more complex benefits. Also a degree should emphasize the mechanism behind any tool since there is no guarantee that git will remain the de facto solution 30 years later.

i did not get the rerere part. i always rebase my branches. if there's a conflict with main branch, i have to resolve it but once i do that the commit is already irrelevant to sub-sequent rebases (after main moves again). why would there be need for this? i feel like if someone is running into same conflict again and again, they have to be doing something wrong -- am i wrong?

I'm with Prime here. Using git can be part of exercises (and seems to be pretty common atm in programming heavy courses like computer graphics where you write tons of C++). But they can figure that out themselves, you don't have to explicitly teach it. If you do then you should go really deep and on concepts that will stay with you when all technologies change in 4 years. Similarly learning specific web frameworks or languages should only be a vehicle to teach the underlying concepts. I've been programming for over 20 years now and it's the concepts that stayed. In school we did COBOL and wrote Snake in assembly, we wrote WinAPI and MFC stuff, worked with Borland C++ in DOS and NetBIOS. BTW that was at what you'd probably call a trade school. A school from age 14 to 19 where about 40% of the time is focused on applied education (we got them for everything from programming, electronics to mechanical engineering and woodworking). It was really good to get a job instantly. I still preferred CS at university after all because it then really taught me the foundations of what I've just been using before.

BTW, couldn't agree more on teaching how to build it (git) and how the distributed algorithms work, how 3 way merge works, etc, etc... Once you know that, using the tool is easy, and you have the benefit of being able to build other systems that use those same ideas (just hopefully not blockchain stuff) :)

28:00 "Always bet against yourself". I totally agree. Always assume you've made a mistake you're not aware of and you'll need to fix the code two years into the future when you cannot even remember writing the problematic line. The code should be as simple as possible to be easy to debug and commit messages should explain *why* the line of code was written in the first place. Commit messages should not explain *how* the code was modified because automatically generated patch already contains that information. It's okay to *also* include summary of changes but it's not replacement for documenting why the code was modified. AI generated commit messages can only do the summary part at best.

Need to learn how and why the abstraction exists before learning the abstraction

Historical fact. In 1890, US universities copied the German model which focuses less on giving a universal education of ARTS and SCIENCES and more on finding which companies will pay the most to the school in order for the school to rain up researchers who run tests, which will return reports that make the businesses look good to increase profits to pay schools more.

Can someone give the details on what it means when git ignore and git exclude are "clean" does that mean FULL of all the files you want to not commit or Empty of files that you don't want to commit AND you just add the files individually, but also I know how that isn't the only other option and both host and guest use git add .

For those who wondered who he was talking about "The man that knew everything" in the 1700s... @14:06 Samuel Taylor Coleridge & William Wordsworth

The most interesting thing about Git is that its implementation is surprisingly simple compared to how much it can accomphish.

My boss loves rebase, I hate it! It causes conflicts constantly! I prefer fetching changes from main, merging into my branch then creating my branch pull request. I get that rebasing might keep the tree a bit cleaner but I've NEVER had a conflict merging main into my branch, yet rebasing my branch on top of main causes issues 80% of the time.

What if your job makes push and merge the only option?

2:15 You could have also just run "git rebase --continue" after creating one or more extra commits. Git will accept that just fine because it specifically supports splitting commits when you "edit" a commit during a rebase. It may mess "git rerere" a bit but everything else will be just fine.

I never nav to top then `git add .`, since I can stay right where I am and `git add -A` in place. Keeps the context of my mind and the current dir coherent.

38:02 Brasil mentioned!

My daughter was in a hackathon at 14 years old, where I witnessed a bunch of children learning Git; on a random mix of Windows and MacOS. Git has to be taught in school. Because teachers without it will give you assignments full of bugs. My daughter actually quit high-school computer science because of all of the drudgery of just catching up to debugged code. High school and college absolutely must teach basic Git as a prerequisite. I think CS professors saying that "teaching git is not my job!" are total idiots. It's a prerequisite to any class where the teacher needs to disseminate code. The teacher ALWAYS has bugs; that get mixed in with student bugs.

The issue with this is that programming without a ruined education is very limiting. Existing vocational trade schools you are thinking of exist, but they are largely terrible at picking good subjects to teach and often hire incompetent people as instructors.

I've been using Git for 10+ years and if I use "git add ." or even "git add -u" that's a huge exception. I'm pretty much always using "git gui" to commit individual lines, not files. I'm basically doing myself a code review while I'm creating the commit and I'll typically catch a stupid typo or some other simple issue before even completing the commit in the first place. It also allows committing logical changes. For example, if I actually fixed one small bug in existing code and implemented a new feature, that should be two separate patches even if both happen to co-exist in my working directory. Basically make as small commits as possible but every commit should be able to be reverted as a single commit. If reverting that single commit makes no sense, then it shouldn't be a single commit. Commits should be atomic.

We used to have 4 year bachelor equivalent trade schools here in the netherlands. But the introduction of the bachelor/master system is messing them up as they all want to be more academic. They were ok, but I still didn't get any courses on source control (git didn't exist yet).

100% agree on teaching version control as part of CS, instead of any particular tool. In my course in 2006-2009, they made us use Tortoise SVN for one of the classes, which I hated the interface of and thought it was garbage, but without explaining version control much, therefore I thought version control was hard and sucky

TIL there are people that add files individually. Or merge instead of rebase.

Really fresh coffee has oil floating on top. Just a few beads but they’re there!!

Spot on with the trade school take. 2-4 year program with hands on building and learning in a tight loop. No todo apps nonsense, no unrelated classes, build real software a company would license or pay the students to build. Like welding and similar trades the graduates would ideally be ready to start a job and be useful on graduation day.

My school didn't so much teach git, they just told us to use it and linked the docs

Pull main into your branch, resolve commits, push and squash back into main. Clean, fast, easy, and hides the horrors that happened on the feature branch. Also supports reverting.

In my CS degree I was taught git in a single session just by going through a ton of commands, but without any explanations on how things actually work or even a demonstration. We were meant to use it for that module but it was so bad that nobody in the room understood it, and we all had to go learn on our own. That being said, I think it's a good thing to learn in school, because you will need it in practically any company you work in. I think being told everything about how it works could be good, but I disagree that there's no point teaching it unless you get told the full implementation. It's not like you get told how a compiler works before you start using it.

27:25 Yes, rebase feature branches unless you have a really good reason to do a merge. No, don't do squash merges unless your separate merges are true hot crap. Keeping historical commits as separate with individual commit messages help you in the future when you have to maintain the code as legacy code and nobody can remember why the code is written as it currently appears. When you have well written history for a project, running "git blame" will result in annotating every line of commit with an *explanation* why that line of code does exist. And that explanation should better be something else but "random commit of my workspace" or "squash commit of half-a-year worth of work for feature X".

I understand rebase is important, i dont know if I'm doing rebase wrong , but they are hard to do

Can't wait to check the git course out. But, Lazygit ❤ check it out!!!

My problem with rebase is that everyone suffers very immediately from a junior coworker’s skill issues

Ok after watching Prime's explanation of why he likes rebasing, I understand all that part of it. The problem then comes when I'm spending 2.5 hrs manually resolving conflicts on every single commit I've made, many times the exact same resolution. I've recently learned you can use rerere but I haven't tried it yet. I'd love to never look at a conflict again and if I do it better just ask me once and move on! What am I doing wrong that's causing me to resolve conflicts over and over for every commit on my branch to get things in line with main?

Unless I am misunderstanding, I think the part about revert is just wrong. It is trivial to revert that with one command. That command is just...revert. That's what git revert does to a merge commit. It's not even some arcane option - it's the default behavior. He makes it sound like he thinks that reverting the feature->main merge will also revert the commits from the main->feature merges, as if you'd have to dig into it and sort the feature commits from the mainline commits that you brought into your branch while you were developing, but you don't - that's the default behavior of git revert. Unless I am misunderstanding, this is a completely wild mistake for someone selling a git course.

We never had a course in CS specifically for git, we had like 2-4, 2 hour sessions that you could opt into, if you did not know git to get the basics down.

16:14 @ThePrimeagen in Germany we actually have vocational training, spanning 3 years for two separate occupations. IT specialist for system integration and IT specialist for software development.

beastco mentioned

My 2 favorite devs

Why Git and not Perforce? How about just Source Control??

Chrome asks the server with "permessage-deflate" header on websockets... So it is supported in Chrome at least. It maybe only supported over https

15:30 sounds like prime talking about a vocational training system. In Germany nobody has to go to a university to become a software developer, you just do a paid, dual (on-site at a company aa well as on-site at a vocational school) apprenticeship as a software developer for three years.

and if they even bother to have us use git, DON'T FORCE US TO USE THE DAMN GUI IN WHATEVER GARBAGE IDE THEY ALSO FORCE US TO USE

41:00 Basically ThePrimeagen elevator pitch for the coffee is "This is targeted to developers and will have the same price as Starbucks but higher quality."

38 minutes in: Brasil mentioned!!!

You know it's interesting about how AI services and things are shifting academia into a newer direction that I think is like how was described as an older, more ephemeral style of grading that required participation in the group. Because homework and reports and stuff like that are basically toast. idk

I learned git on college, graduated like 10 years ago Went to SUNY potsdam and they had their own git server, and all the computers in the comp sci computer labs ran Linux

git push --force-with-lease aliased to gpf for safe and fast push forces

29:20 would you not just push a revert commit??

I’m deep in the sauce and I still do git add . , git commit, git push… I just run git status and git diff -staged 400 times before because I’m apparently cyber ocd

22:00 it will walk the first-parent. In Git, first-parenet of a merge commit is the current checked out branch while merging. So HEAD~2 will walk the first parent path. Specificying the first-parent argument when running git log is really nice cause it takes out all the noise of side/feature branches.

why would rebase or not be a question what

Finally I might end the debate. "Why use neovim? VSCode so pretty. VSCode so kewl" but can it order COFFEE?

I learned git at work when the R&D team started letting me do bug fixes

Good grief, we had trade schools, polytechnics, apprenticeships up til the 1970's. Only 10% of kids went to university to float away in academia and research etc. Since then we had the big push to get every kid a "university" education, which involved renaming all the trade schools and polytechnics to "university". Along with the whole disaster of kids having to borrow piles of money to do the study that is now demanded of them. No longer any chance to get a grant or work and study. And of course the bachelors degrees simply got devalued, unless you were one of the luck few to go to a traditionally renowned university. I have been watching this disaster unfolding since I graduate in 1979.

lol its funny thats how things were in the late 90s early 00's for Web Development. It was considered a trade at that time...Honestly I think they should keep the CS Model for the first 2 years and the second 2 is a straight up bootcamp...similar the Software Engineering degree but more in depth.

If your CS curse didn't teach you GIT by year 3, you should be able to get full refuns in that shit. It's literally like if driving class would just nit teach you how to check oil in your car, cause "it's theory of driving, not real driving here".

git add -u is the perfect compromise

I use lazygit. I still do file by file cuz it also gives me a chance to kinda glance review but with lazygit its easy. I dont feel safe adding all 😂

You can revert a merge as well. Not just commits. So the argument at 27:00 is not really good in my opinion

Before Git, We learn FTP, then SCP and Rsync

a tool is something you gotta respect and so, I hear ya about, when schools teach git, but don't teach it properly, they are giving people credit for knowing something they don't really know. And it comes across anyway as, they don't respect the tool

Ahh, the deep words of Samuel Coolranch.

So. Prefer tea over coffee (well I just don't like coffee at all) Indeed. I rebase my branch as much as I want to, until I made a pull request and need to fix comments. Then squash and merge when done.

Did I just watch Prime invent run length encoding in real time?

8:29 that’s a good take. Uni should teach how to build git, not how to use git.

I don't think universities should teach any specific tools, but rather more theoretical foundations which are universal and don't become that quickly stale. Teaching specific tools / languages is totally fine for more vocational institutes where you need to learn stuff that is directly applicable at work. Having said that using particular techs/languages as an example is probably great idea, but I'd rather see graph theory and conflict resolution algorithms taught at unis than particular tool

Prime's sweatshirt dead giveaway "dad with small kids"

Always rebase your branches before merging a pull, and generally squash merge each pull request. If you rebase frequently, any issues rebasing are very manageable. And if you feature branch gets really big (and does and undoes and modifies itself in a place that may have changed on main) then you can squash some of your commit in the branch and then rebase.

Friends, 'git add -u' is the way

Technically, I have a proposal. What if we remove useless degree. Like instead of having phd or masters, we should just have professional degree. So you can have bachelor's degree in computer science (this teach you the basics and fundamental concepts) Then you can get the Professional degree (which teach you businesses setting, corporate, how programming is done in those setting) Just to note. Every business and company is different. You can't technically teach everything, but at least Professional Degree should teach you how real world works.

Bachelor's degree in Sweden is 3 years.

I don't even do git add . That's too much repetitive typing Git config --global alias.cmt "git add ." && "git commit -m" That might not be totally correct from memory but then you just type git cmt and it adds all the files and you add a message all in one go.

Where is his git course ?

I really like actually preserving the history of the existence of a branch. I cut feature branches from master, rebase them back on master whenever master has changes, and then I _merge_ the feature into master when it's done. Then if my feature has a critical bug we revert the entire merge. Edit: also git push --force-with-lease exists and is wonderful.