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.
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.
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.
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.
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.
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❤️
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.
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!
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.
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!
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.
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.
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.
My extension school masters degree had a number of classes taught by working professionals. One class required us to use git throughout the course but one lecture did cover setup and config and we got familiar with it. It was helpful in future jobs. That degree was a great combination of typical academics (cs theory if you wanted it) and practical almost job training.
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.
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.
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.
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.
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.
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.
@@marioprawirosudiro7301 You can't just add them to a git ignore. Unity meta files sometimes need to be adjusted. Because they positioning and more game object values. I don't know what it was but something slightly adjusted every unity object in the scene after I saved. Sorry, but you not very convincing. We all make mistakes, and looking at you work before committing is probably going to help in the long run as a professional.
@@jeremylakey680 I know. This is one of the biggest reasons why I moved away from Unity. Back then my solution was to ONLY include the scripts, zip away the corresponding meta folder and share it on a file sharing site so my teammate can have the same ones, effectively treating the meta files as blobs (which tbh, it effectively is). We did this for every commit. It was tedious, but still better than dealing with the incessant messages because the meta files keep changing.
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.
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.
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.
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?
It's just the way rebase works, it goes back over older commits to make sure that nothing snuck in so it can recompare to the same older commit that caused an issue multiple times; its not that the conflict happens multiple times it's that its reanalyzed multiple times so rerere tells it to just redo the same fix you did the first time when you reanalyze the same conflict (should be a default really but omission from the original version and linus refuses to ever change a default no matter how ridiculous the old default was)
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.
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".
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.
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.
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.
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.
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.
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.
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.
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).
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.
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 .
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
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.
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."
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.
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.
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.
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.
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
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
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.
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.
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) :)
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
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.
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
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.
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.
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.
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.
I like rebasing too, but when I know I'm working with someone else on the same branch I always merge, saves you the trouble of having to worry about force pushing over someone else's changes
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.
@@OnlyForF1 but typing commit is too long haha I just want to type cmt. Or do you mean in the alias? I think I might have tried that but git didn't like it for some reason.
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
@@backendbanterfm Of course I use gitignore. But sometimes you just create a random file when tinkering with something, thinking you'll delete it. It may happen even with gitignore. Especially when you have few hundred people editing the code, it is a good company policy to warn against git add . Remember, what might happen, will happen. And honestly, git add src is just 2 symbols longer and is less likely to have some random files in src dir.
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.
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.
The problem with rewriting history is that you as the programmer are saying to git "hold my beer, I know what I'm doing". This is ok if you do... It's disastrous if you don't. If you just use merge and don't rewrite history, then other than dealing with merge conflicts (which there will be fewer of), git will just do the right (correct) thing... This is what most casual devs want. Should we live in a world where all developers know their tools and are experts, probably yes... All the open source peeps do use git this way, (because they mostly have to but also because they know how)... On your average developer team in Corporate America or Corporate World, they don't know, they're not going to learn... It's much safer for them to not rewrite history, (and to be fair I'm lazy and I also just like the tool doing it for me). edit... I should mention that when you rewrite history, if you end up duplicating commits (which you shouldn't if you know what you are doing), by eliminating the merge commits, you destroy git's ability to deal with that problem automatically... the DAG is what git uses to figure out what to do (or at least what to try). If it's all linear, then it's the same as subversion.
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
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
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.
real question is, was it written in clojure ;)
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.
@@GDScriptDude seems like you answered your own question
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.
if you're using git as a backup tool, you're probably using the wrong backup tool. eg. borg backup would probably serve you much better
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 .`
Same
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.
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 feel you so bad, my Uni added an enterprise software development Master's
then apply to a different school moron -- not every masters program is the same -- find one that is more theoretical and less applied
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.
Then make ur own course like Primeagen
I graduated from my school RIGHT BEFORE they reformed the curriculum to be more software engineering. I took ONE project course.
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.
The field moves too fast, but seems to be coming to a consolidation point. Also teaching CS is really hard.
@@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.
Look into brushing and communications classes in electrical unions, they are literally the trade schools you are referring to.
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.
Said that way... It sounds depressing.
Vain ?
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.
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❤️
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.
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!
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.
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!
@@euclid9492 I forgot to mention, college here is significantly cheaper than university too.
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.
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.
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.
My extension school masters degree had a number of classes taught by working professionals. One class required us to use git throughout the course but one lecture did cover setup and config and we got familiar with it. It was helpful in future jobs. That degree was a great combination of typical academics (cs theory if you wanted it) and practical almost job training.
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.
"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.
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.
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.
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.
Or you know… tell them to download the zip lol
@@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.
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.
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.
No, you can still use "git add .". Just have to put those meta files in ignore.
@@marioprawirosudiro7301 You can't just add them to a git ignore. Unity meta files sometimes need to be adjusted. Because they positioning and more game object values. I don't know what it was but something slightly adjusted every unity object in the scene after I saved. Sorry, but you not very convincing. We all make mistakes, and looking at you work before committing is probably going to help in the long run as a professional.
@@jeremylakey680 I know. This is one of the biggest reasons why I moved away from Unity. Back then my solution was to ONLY include the scripts, zip away the corresponding meta folder and share it on a file sharing site so my teammate can have the same ones, effectively treating the meta files as blobs (which tbh, it effectively is). We did this for every commit. It was tedious, but still better than dealing with the incessant messages because the meta files keep changing.
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.
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.
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.
29:20 would you not just push a revert commit??
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?
It's just the way rebase works, it goes back over older commits to make sure that nothing snuck in so it can recompare to the same older commit that caused an issue multiple times; its not that the conflict happens multiple times it's that its reanalyzed multiple times so rerere tells it to just redo the same fix you did the first time when you reanalyze the same conflict (should be a default really but omission from the original version and linus refuses to ever change a default no matter how ridiculous the old default was)
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.
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".
Where is his git course ?
Frontendmasters
www.boot.dev/learn/learn-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.
For those who wondered who he was talking about "The man that knew everything" in the 1700s... @14:06
Samuel Taylor Coleridge & William Wordsworth
Hey Huffman is a half-measure. Have a look into the Arithmetic Encoding. It can encode things in LESS then one bit.
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.
You can revert a merge as well. Not just commits. So the argument at 27:00 is not really good in my opinion
What if your job makes push and merge the only option?
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
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.
@@test-zg4hv git gui, lol
I recommend reading Git book, chapters 2, 3 and 7. It helps a lot if you want to understand it properly.
Use magit kek
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.
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.
14:23 I wish I could do that for the subfields of computing science "only"
why is rerere off by default?
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.
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.
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).
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.
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 .
why would rebase or not be a question what
I always add each file to git because I like seeing the diffs and sometimes catch something I wouldn’t have otherwise before committing.
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
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.
My problem with rebase is that everyone suffers very immediately from a junior coworker’s skill issues
That's....fair
TIL there are people that add files individually. Or merge instead of rebase.
38:02 Brasil mentioned!
I understand rebase is important, i dont know if I'm doing rebase wrong , but they are hard to do
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."
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.
Need to learn how and why the abstraction exists before learning the abstraction
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.
34:18 you’re not rewriting history of that history hasn’t happened yet… like a feature branch
Berkeley EECS 61B teaches how to implement a Git client. We were already expected to know git use on our own.
Chrome asks the server with "permessage-deflate" header on websockets... So it is supported in Chrome at least. It maybe only supported over https
The most interesting thing about Git is that its implementation is surprisingly simple compared to how much it can accomphish.
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.
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.
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
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
Thought Prime was gonna lose me on his super spicy take, but he nailed it!
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.
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.
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
beastco mentioned
Shout-out beastco
What is SST?! And what is a Mullet stack?!
Add some "evil merges" in that Git training. Lol. Those are always fun.
Rebase makes the history nicer. Seems to be my experience as well. We all start of as merge, but then discover the awesomeness of rebase.
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) :)
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
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.
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
It wasn't for a specific class or anything, one professor just required you to use it for any assignment you submitted
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.
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.
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.
Seems like understanding the challenges of distributed systems would be a good idea.
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.
rerere
I like rebasing too, but when I know I'm working with someone else on the same branch I always merge, saves you the trouble of having to worry about force pushing over someone else's changes
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.
Just use git commit -am
@@OnlyForF1 but typing commit is too long haha I just want to type cmt. Or do you mean in the alias? I think I might have tried that but git didn't like it for some reason.
Finally I might end the debate. "Why use neovim? VSCode so pretty. VSCode so kewl" but can it order COFFEE?
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
8:29 that’s a good take. Uni should teach how to build git, not how to use git.
git add . is just too easy to include additional stuff, I do 'git add src' and never make targets build into src dir
.gitignore ?
@@backendbanterfm Of course I use gitignore. But sometimes you just create a random file when tinkering with something, thinking you'll delete it. It may happen even with gitignore. Especially when you have few hundred people editing the code, it is a good company policy to warn against git add . Remember, what might happen, will happen. And honestly, git add src is just 2 symbols longer and is less likely to have some random files in src dir.
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.
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.
The problem with rewriting history is that you as the programmer are saying to git "hold my beer, I know what I'm doing". This is ok if you do... It's disastrous if you don't. If you just use merge and don't rewrite history, then other than dealing with merge conflicts (which there will be fewer of), git will just do the right (correct) thing... This is what most casual devs want. Should we live in a world where all developers know their tools and are experts, probably yes... All the open source peeps do use git this way, (because they mostly have to but also because they know how)... On your average developer team in Corporate America or Corporate World, they don't know, they're not going to learn... It's much safer for them to not rewrite history, (and to be fair I'm lazy and I also just like the tool doing it for me).
edit... I should mention that when you rewrite history, if you end up duplicating commits (which you shouldn't if you know what you are doing), by eliminating the merge commits, you destroy git's ability to deal with that problem automatically... the DAG is what git uses to figure out what to do (or at least what to try). If it's all linear, then it's the same as subversion.
I learned git at work when the R&D team started letting me do bug fixes
Can't wait to check the git course out. But, Lazygit ❤ check it out!!!
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
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
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 😂