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❤️
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
my 3. I often sneak in smaller drive-by fixes like docstring lies or small refactoring -- so this is how i can split them into separate commits ..which I then might or might not throw away if i change my mind. so it's also a way to lower the barrier of making these quick fixes because i can now rely on myself reviewing and reconsidering them later without putting the main thing in danger by dumb things actually sneaking in via `git add .`
I usually add code as logical blocks, normally parts of files or multiple files, and try my best to ensure that each commit is runnable. This gives me a sensible development history and is very useful with git bisect, which itself is very useful when I later find a strange bug, but cannot identify the source of it.
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!
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" :/
Interesting, i am on the other side of this, i want to learn more practical work habits skills in my masters degree but the school where i live has a lot of theoretical classes.
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.
@@ChrisAthanas I'm not so sure about that. Here in NL kids are separated into tracks early high school. These lead to trade school, science education, and something in between. IT and programming education exists on all levels. The in between level, which I think is what prime is thinking about is a 4 year degree, but you get to leave highschool a year early compared to the university track.
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.
Yeah... there are certain tools every CS student should learn, and Git is one of them. Version control, debugging practices, and an example of a build system should be mandatory stuff you learn.
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.
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.
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.
@@ar_xiv that's exactly what the problem is. most of the kids download the zip. they can't get the example to work. the teacher has YET ANOTHER bug; almost every other project. if teacher keeps putting out new versions, it's chaos when the patches come in over the buggy code that the kids are writing. Rather than.... teacher diffs to see what the kids did, and merging the teacher's bug fixes. "just send zips around", or "just put code in a directory" is why git was created in the first place; to stop that madness of multiple editors on the same archive.
I feel this. No so much that they need to teach git, but that requiring the subject will force teachers to learn it, and thus improve the deployment of their assignments. That makes sense. Assignments of complexity can make the learning more "cool". But deployment of assignments with complexity requires a level of ops sophistication many teachers lack.
@@robfielding8566bro idk what school you went to but my teachers use Linux and CML and bash to make sure all files follow same format and syntax and don’t have bugs
@@ryanfeeley2407what projects do you think students work on? Their not projects that build , their usually stand alone 2week-1month projects . A student submits it and moves on. GIT has no place in this . These aren’t mass contributed projects
It's weird how many people think there was no source control before git. No, people weren't forced to email zip files back and forth before git. There was actual source control software before git, and it was often more intuitive than git is now.
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.
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.
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.
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.
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.
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.
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.
That actually sounds amazing. Teach practical job stuff first and then go conceptual once you know students can do some form of basic programming job. I got a Software Engineering bachelors in the US thinking it would be more practical than CS. Only took a single web dev course senior year and just got more math requirements than CS to get the coveted “engineering accreditation” and did way too much UML. I think we could learn from Canada here!
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.
I have been questioning why I use git for personal projects and recently set up an automated hourly (rsync) backup of my dev files to another disk on my computer. A missing feature is to have some historical backups to rewind changes.
Most developers rolled thier own backup routine before source control became popular. We were all forced to when we lost our work just once, maybe twice for a slow kid like me.
I learned git the same way i learned what a vtable is: smashing my head and google. Specifically the "git stores changes in code". No, it stores the entire code, then does some behind-the scenes work, a very important implementation detail. Especially important if trying to understand merge conflicts. And what it means to "erase" a commit. You arent erasing changes, you are erasing snapshots. Same with the stage/index, same with the c++ compiler complaining about emitting a vtable because each distinct translation unit with a class declaration emits its own vtable for its virtual functions. Which is really funny in the very specific case where you compile a file with a virtual class, then copy-paste the declarations in a header out of lazyness, then compile another file with both the header and the original object, as now both have different vtables. Have i mentioned that the vtable pointer in virtual classes can be, oh idk, accidentally edited by something like a buffer overflow? And it isnt visible as a field in most visual debuggers? C++, the C for the layman and deranged alike.
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.
In Denmark, we have the concept of a "trade school" kinda engineering alternatives to the more traditional university bachelor+masters. They are shorter (3.5 years) with half-a-year of mandatory internship in a company with other engineers. All the courses is industry-oriented (more practical and less theoritical) and we learn the techonologies in demand here (C#, Git, HTML/CSS, React, SQL, Testing, CI/CD etc.). At the same time you get a bachelor in engineering, where you can either go out and work or study for a masters of science in engineering (a few foundational physics/math electives are necessary to go this path). This education is offered for lots of fields, like civil engineering, computer/software engineering, bio/chemical engineering, mechanical etc.
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.
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.
Definitely on board for trade schools being prioritized. I think bootcamps are a great format for updating your skills and getting familiar with new technologies, so amend them instead of removing them. But university education has become overblown, especially with how much it costs in the US.
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.
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.
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.
Honestly I have senior (senior, senior) devs in my team that use a git frontend and have no clue what is happening in the background. It's insane the checks and config scripts we need to add to make sure people don't fuck up our repository. I feel like it has gotten better with newer devs, as they tens to at least use the CLI.
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.
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.
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.
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
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.
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.
Or... you just use git feature built into intellij. I have used so many git tools as well as git cli and there's nothing easier and faster to use than the feature simply built into intellij. No git add -a. Everything you want to be added is just automagically added
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) :)
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.
At my university, we actually learned computer science. When it came to tooling, the tutor would usually say something like "I'd recommend to use git or svn, btw." and then interested students would go forward, study that by themselves and use it. Learning tools and programming languages should at most be a footnote in a university course, never the actual content.
Plastic is much better for a starter. It is for the most part orienting to gamedev but not limited. I have seen people take use of it quite fast and we have no too bad situations.
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.
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).
There is a technical college in my area that has programs on programming, engineering, auto mechanics and i think something else. I never attended but if i was going to a college for cs, thats my number 1 choice.
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".
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.
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.
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.
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."
Just think about kids at CS programs who are trying to learn git when they don't understand all the foundational concepts that it relies on. If you don't know about hash functions and content-addressable databases, how can you understand git commits? If you don't understand trees and pointers and graphs, how can you understand git history and branches? If you don't know what a stack is and the push/pop interface, you'll learn about git stash and most of your confusion will be about stacks, not about git stash. Git is a good way to get quickly exposed to a lot of programmer culture in an informal way, just like any other good command-line tool. But an academic program should take a more systematic approach to learning the concepts in a more formalized and in-depth way, not just hold your hand through learning to be a consumer, like some sort of wildly expensive boot-camp.
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
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
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
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.
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.
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
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
Implementing version control would not teach fundamental CS aspects like implementing a compiler or OS. So implementing version control would not be the best use of time. Teaching the basics of using version control is a good idea because it is a great tool. Much like teaching LEX and YACC is a great idea. But schools should stick to the basic fundamentals of CS - basically the stuff that does not change. People can learn the stuff that changes quickly on their own.
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.
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.
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.
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?
rerere is just a config toggle, there's not "using it" specifically. So if you're still in the "ive heard of it but havent tried it yet" just do it, this is your signal
I personally don't use GIT that much, basically because I used to trust in my own criteria when merging code and not leaving it to a merging tool (completely), sometimes there is bussiness decision to be made in order to know which code has to be pushed to remote. I usually do pull after push and if there's a conflict I revert the whole thing and resolve it with Beyond Compare (or any diff tool you wanna name) all in local before pushing to remote, it gives me peace of mind always. I always hear from colleagues "you will never be a senior developer if you don't learn all the bells and whisles of GIT, blablabla", but I rather to learn other skills that gives value to the product and help to solve problems, so I choose the tools and how I'm gonna do it, mind your own businesses. I mainly do this because i'm not vegapunk from onepiece, the amount of tech skills you can attach to your head is not infinite so I choose which to master and which to learn the very basics.
