Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.
Let me start by saying this is wonderful work. Thank you for creating such a comprehensive resource. I haven't read through it all, but one thing did catch my eye.
> The default branch used to be called master, and still is called that in some older repos.
This is not true. Git still defaults to `master`, but allows you to change the default (for future `git init` invocations via `git config --global init.defaultBranch <name>`)
Again, thank you. If I find anything else, I will be sure to post here.
*Update*: I also feel that referring to "older repos" sends the wrong message. *GitHub* decided to make this change, causing others to follow, and finally Git itself allows for the aforementioned configuration, but it has little to do with _newer_ or _older_, but rather preference.
Just a quick shout-out; I was one of the many many students you taught at Lambda School, and just wanted to say your instruction was one of the highlights of my time there. Thanks for doing what you do!
Not wrong, but worth mentioning. I really found git worktrees to be crucial to my workflow and have heard very few people mention them or even know they exist. Excellent way to keep your branches from getting their streams crossed without the headache of dealing with stashes.
Actual Beej? Wow I remember absolutely loving reading your networking guide. It taught me so much and really showed me the depths and breadths of what can be done in code, how the net works (pun unintended), it was a great experience for me as a kid. Thanks! <3
I found your networking guide as a kid with only some scripting experience, and it served to get me into C programming in general, so I have a special fondness for it.
Appreciate the work! Neat to see you still writing pieces like this all these years later!
Not wrong of course — thank you for your amazing guides! But feedback re: "15.7 Multiple Conflicts in the Rebase":
There are two things I suggest as workflows for people when I teach them about rebase workflows.
> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...
For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.
For instance, if forked from main:
git rebase -i `git merge-base main --fork-point`
Squash all of those, and then as usual:
git rebase -i main
Second, when rebasing repeatedly onto an evolving branch over time, you'll often find yourself resolving the same merge conflicts over and over again.
Unrelated; I just wanted to say that I learned programming from your socket tutorials when I was a kid. Everything was so well written that I used it from highschool, to varsity to my day2day job.
Without your tutorials I’m not even sure if I would have chosen the carreer I did- thank you for all the love and effort you put into your posts; Im sure that there are many other people who you’ve touched in a similar way
Beej, your Guide to Network Programming helped me through my early UNIX career. In fact, your guide was so influential to so many people, it very quickly became recommended reading in my university's network course.
I'm delighted to see that you're still active and still producing guides. Well done!
Along with many others here, your network programming guide helped me so much back in the early days of my education and career. So thanks for that too…
Hey great work beej! I've read pro git and your guide is very good.
So in figure 5.4 you say we merge 2 commits into a new one and somehow both branches point to new commit. This will definitely confuse people new to git.
I'd say it's better to write we merge anotherBranch into someBranch and leave the former where it is. Same for the next merge.
> But in this section we’re going to be talking about a specific kind of merge: the fast-forward. This occurs when the branch you’re merging from is a direct ancestor of the branch you’re merging into.
Looks like "from" and "into" are swapped: "main" is "into" there, "newbranch" is "from", and "main" is a direct ancestor of "newbranch".
joining the crowd to say thank you. i've been using your materials for over a decade.
in my experience, strong writing and communication skills are one of the best ways to stand out as an engineer -- and your articles are maybe the best example of this out there. keep on setting a great example for us. :)
Not wrong, but something I found confusing, in section 2.7.5 (page 11 of PDF):
"Let's say you modified foo.txt but didn't add it. You could: <git command>"
Followed by:
"And that would add it and make the commit. You can only do this with files you added before."
Wait, what? So, I modified foo.txt but didn't add it, and then the command to add and commit at the same time can only be done with files I did add before?
Guide was working great to heal years of git trauma up until that point though!
I remember reading the excellent Beej's Guide to Network Programming[0] and Beej's Guide to Unix IPC[1] as a teenager, which were incredibly approachable while still having depth—fantastic reads both and very influential on the programmer I ended up being.
Same here! I was also a teenager in the mid-90s. And I was amazed by IRCd server code and bots. I bought a used copy of the book Slackware Linux unleashed w/CD-ROM and it had some networking code examples in C. I found Beej's Networking site because I was confused by a lot of that networking code. Became even more obsessed and went a deep rabbit hole. I spent a lot of time visiting different book stores hoping they had programming books. Bought Richard Stevens' amazing reference books and never looked back. Thanks for enabling my passion all these years later Beej!
I remember translating Beej's network guide to Italian while learning how to use select, which I wanted to learn to make some port scanner ("grabb' I think?) go faster. Fun times.
Came here to see if it was the same person, though I felt very sure with the throwback web design - back when each page had its character, and you had to save the page for offline reading so that Dad wasn't pissed at the phone bill!
And when the code worked - it was validation against all the previous failures (and rejections) in life! Oh the joy of sending message from one computer to the other!
I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old.
To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language.
More on topic, this guide would've been super useful when I was learning. It is really easy to follow and covers common FAQs.
I fondly remember being intimidated by my first merge conflict, aborting it and just doing some workarounds to prevent the conflict.
Git switch is fairly new, it first shipped in 2019.
Here's, respectively, a discussion from 2021, and a discussion from a few weeks ago. In the latter, it's brought up that `git switch` is still considered experimental by the docs:
> I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old.
I don't think "git checkout" is considered the "old alternative", at least not yet. Last time I checked, `switch` is still experimental, I haven't even considered moving away from the workflows/commands I first learned when I picked up Git ~15 years ago. Everything I want to do still works exactly the same (`git checkout` still does the exact same stuff as before), and I'm able to collaborate with everyone else using git, why change workflow then?
Why are programmers so vehemently angry over the fact that a complex tool which does complex things to a complex data structure might have some complexity to it?
My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page.
Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index is a tiny proto-commit still in progress that you "add" to before committing.
There. That's git. Want to know more? Don't read the guide, just google "how to I switch to a specific git commit without affecting my tree?", or "how do I commit only some of my changed files?", or "how to I copy this commit from another place into my current tree?".
The base abstractions are minimalist and easy. The things you want to do with them are elaborate and complicated. Learn the former, google the latter. Don't read guides.
Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts.
Git plumbing's definitely a bit more obscure, and does a bunch of stuff on its own that you can't always easily do with porcelain commands because they're optimized for the common use cases.
TL;DR: while Git's big (huge even), a lot of what it provides is way off the beaten path for most devs.
Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use
Learning git like this is honestly just hampering yourself
I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year). I literally take them into the .git directory and unzip the files to show how everything is just plain text representation of basic data structures. It's honestly cool to see it click in their heads.
We have a basic Git cookbook we share with any new joinees so that they start committing code, but most of them just follow it religiously and don't understand what's going on (unsurprisingly).
However, literally everyone who attends the course comes out with a reasonable working understanding of Git so that they know what's actually happening.
That does NOT mean that they know all the commands well, but those can be trivially Googled. As long as your mental model is right, the commands are not a big deal. And yet, the vast majority of the discussion on HN on every single Git post is about the command line.
Funnily enough the class sounds a lot like the alt text of https://xkcd.com/1597/ (Just think of branches as...), the difference is that that is unironically the right way to teach Git to a technical audience, and they will come out with a fundamental understanding of it that they will never forget.
I honestly think it's such a high ROI time investment that it's silly to not do it.
I did it once, I was indeed really nice, and the discussion that we did after was very cool. I put in the last slide of the presentation some questions for my colleagues answer based on the Git data model, e.g.: "Can we move a commit to another branch?" or "What guarantees that we don't have cycles in the commit graph". I was really satisfying that people came out thinking Git, not only using it!
> As long as your mental model is right, the commands are not a big deal.
A priori, I would have assumed this was one of those "just understand how every layer and every part of Linux works, and using Linux is easy" type arguments people used to make in the 90s - i.e. theoretically true, practically infeasible for most people.
Thankfully, I was lucky enough to come across a video explaining (some of) the git internal model early on, and it really doesn't take that much or that deep a knowledge of the internals for it to make a big difference. I'd say I know maybe 5% of how git works, and that already gave me a much better understanding of what the commands do and how to use them.
> I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year)
Does the course material (and perhaps any recordings) have any proprietary information or constraints to prevent you from sharing it publicly? Is this based on something that’s publicly available yet concise enough to fit within two hours? If yes, please share (perhaps in this thread and as a post submission on HN).
I’m asking because I believe that there can never be enough variety of training materials that handle a topic with different assumptions, analogies, focus, etc.
I'm decent with git (usual flow, merging, rebasing, etc). I'm seriously considering switching over to jujutsu instead of becoming "better" at Git. jj is compatible with git and you can use it while your teammates can also just use git.
I feel like there is a trick that is missed by many guides (including this one) and most git GUIs I've looked at (with notable exception being magit).
That is, to set your upstream branch to the branch you want to merge into, aka the integration branch. So instead of setting upstream of "feature/foo" to "origin/feature/foo", you would set it to "master" or "origin/master".
This simplifies a lot of things. When you run `git status` it will now tell you how far you have diverged from the integration branch, which is useful. When you run `git rebase` (without any arguments), it will just rebase you on to upstream.
Setting `origin/feature/foo` to upstream is less useful. Developers tend to "own" their branches on the remote too, so it's completely irrelevant to know if you've diverged from it and you'll never want to rebase there.
If you set `push.default` to "current", then `git push` will do what you expect too, namely push `feature/foo` to `origin/feature/foo`.
In the collaboration section, the guide doesn't mention feature branches at all. Isn't that a very common way of working? Contrasting it to the "Everyone Uses Their Own Branch" approach described in the guide might be informative.
Also, reusing branches for GitHub pull requests (vs. creating new branches for each PR) might warrant some discussion in section 17?
Haven’t checked out the article, I’m sure its great. But another reco is boot.dev’s git course taught by Primeagen. It’s interactive and He goes real deep down to manipulating files in the .git directory. Came out of that course with a whole new mental model of how git works.
Love seeing this. Beej is one of the greatest in our industry. His educational content is top notch and always free...an increasingly rare thing in the age where everyone tries to monetize their knowledge via paid courses and newsletters.
I think the biggest problem with CVS is the lack of consensus on what and how to push to the repo.
On one hand you have the ideal world scenario when each and every change is granular and you can annotate and blame every single line of code with description. On the other hand you have a real world where teams are encouraged to squash changes so that every commit corresponds to a business requirement and you have to engage a whole cabal to smuggle a refactor.
A long time ago I've implemented a routine to use both SVN and GIT, so that I could use GIT on file save, and SVN on feature release. I think it was inspired by Eclipse workflow. Definitely not something I would recommend these days.
On the promise of going back in time, I’m finding myself getting more utility of VS Codes timed snapshots than my own commits.
I find it hard to judge when things are in a good enough state to commit and especially good enough to have a title.
I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function. Snapshot works pretty well for that, but got isn’t really centered around snapshots and doing good snapshots is not straightforward, at least to me.
I'm going to cheat and say I use a different VCS, but I do really like Jujutsu's approach here.
It has this idea of mutable commits, so essentially you can check out a commit, and then whenever you change a file, the commit is updated with the new file contents. Then internally, whenever a commit gets changed (or any aspect of the repository) that gets recorded in an append-only log. At any point in time, you can scroll through that log and restore any previous repository state, including changes to individual files.
By default, Jujutsu does the snapshotting thing (i.e. updating the commit with the contents of the local files) every time you run the `jj` command. However, you can set up file watchers so that it does the snapshotting every time a file changes in the repository. If you do this, you should be able to browse through the op log and see all of the changes you've made over time, including reverting to any of those stages when necessary.
In fairness, I've not tried the file watcher thing out personally, but being able to review the op log is fantastic for trying to go back to previous versions of your repository without having to do teeny-tiny "wip" commits manually all the time.
A commit is literally a snapshot :) It is also very easy to make.
Stop worrying about titles and content and commit to your heart’s content.
When ready, restructure those snapshots into a coherent story you want to tell others by squashing commits and giving the remaining ones proper titles and commit messages. I use interactive rebase for that, but there are probably other ways too.
> I find it hard to judge when things are in a good enough state to commit
Work in a feature branch. Commit often. Squash away the junk commits at the end.
> ...and especially good enough to have a title.
Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor.
I treat commits in a private branch the same as the undo log of the text editor. No one cares about the undo log of your editor as they never see it. The same should be true of your private feature branch commits. They are squashed away never to be seen by human eyes again.
When working together with other people using Git, I commit fast and often. My commit messages can be anything from "jdwqidqwd" to "add widget frubble() method" while I'm working. Sometimes repeated several times over, sometimes I remember to hit the "amend" checkbox. Basically, whenever I'm somewhat satisfied with the state of my program, I commit, finished or not. Everything in a nice, local, separate branch, pushed occasionally to make sure I don't lose any data.
And then when everything works, compress commits into a few big commits with squash, and actually try to merge that back into the main branch.
> I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function.
For me, that would easily be three commits in my dev branch (one with a first implementation of the function, one with a refactor to a class, then another one back to a single function) and when the function is finished, one squashed commit in a merge request. If everything goes right, it's as if the class file was never there.
It has to be said, relying on squashing doesn't work well when you're working in a team that doesn't pay too close attention to merge requests (accidentally merging the many tiny commits). You also have to be careful not to squash over merges/use rebase wherever possible so your squashed commits don't become huge conflicts during merge trains.
When I work on my own stuff that I don't share, I don't bother squashing and just write tons of tiny commits. Half of them leave the code in a non-compiling state but I don't necessarily care, I use them as reference points before I try something that I'm not sure works.
There is something to be said for carefully picking commit points, though. While finding the source of a bug, git becomes incredibly powerful when you can work git bisect right, and for that you need a combination of granularity and precision. Every commit needs to have fully working code, but every commit should also only contain minimal changes. If you can find that balance, you can find the exact moment a bug was introduced in a program within minutes, even if that program is half a decade old. It rarely works perfectly, but when it does, it's a magical troubleshooting tool.
Oh my goodness, this is a huge treat. His class networking programming guide sits at one of my top books of all time. Well written, informative, concise, and legitimately get you to chuckle out loud at points.
Edit: Does anyone know a good way to convert one of the HTML pages into an epub for reading on an ereader? The PDFs will definitely work, but wanted to see if anyone knew of any tools for HTML -> EPUB conversion.
I have nothing but fond memories of reading Beej's guides.
It's also this sort of work that's becoming less necessary with AI, for better or worse. This appears to be a crazy good guide, but I bet asking e.g. Claude to teach you about git (specific concepts or generate the whole guide outline and go wide on it) would be at least as good.
Seems more efficient to have one reference book rather than generating entire new 20 chapter books for every person.
I also think if you are at the “don’t know what you don’t know” point of learning a topic it’s very hard to direct an AI to generate comprehensive learning material.
I don't get this type of attitude. Surely using the source signal, before an LLM add noise would be much preferable. Besides, there seems to be heavily diminishing returns to de-noising LLM output, and even a hard barrier to how much we can denoise it. Yet people claim they prefer the noisy data and don't consider the risk that they are learning the noise instead of the signal because they have by definition no way of knowing what is signal and what is noise when they ask an LLM to teach them something. Because the noise is friendly sounding and on demand?
I don't disagree, but since the quality of AI is largely a function of the quality of human content, there's always going to be value in well-written human content. If humans stop producing content, I think the value of AI/LLMs drop significantly as well.
I am not a git fan. After many years (following use of RCS, SCCS, CVS, SVN) I tried it and found that its whole mental model was weird and awkward. I can get around in it but any complicated merge is just painful.
Anyway, the comment I really wanted to make was that I tried git lfs for the first time. I downloaded 44TB (https://huggingface.co/datasets/HuggingFaceFW/fineweb/tree/m...) over 3-4 days which was pretty impressive until I noticed that it seems to double disk space (90TB total). I did a little reading just to confirm it, and even learned a new term "git smudge". double disk space isn't an issue, except when you're using git to download terabytes.
I'm really interested and really hoping this is something I can sink my teeth into. I've always had frustrating experiences with trying to wrap my head around git and have to regularly use it at my job.
Branching, making commits, and creating pull requests come easy, but beyond that, I know utterly nothing about it.
One mistake that I see people making about Git is trying to learn more commands, more flags, more tricks, but not trying to really understand how it works. Perhaps it's your case. You know Git enough to use in your daily basis, so maybe it's time to dive into a lower level and then everything else will be natural.
I strongly suggest reading Pro Git, the official Git book by Scott Chacon and Ben Straub, available for free here: https://git-scm.com/book/en/v2.
I find it very pleasant to read and it really changed my perspective not only about Git but about how to write code in general. You don't need to read it entirely, but suggest at least these sections:
- 1.3 Getting Started - What is Git?: explains a little about snapshots and the three states
- 10.1 ~ 10.3 Plumbing and Porcelain, Git Objects and Git References: this explains Git in its lowest level, which is surprisingly simple but powerful. Those sections were enough for me to write my own "Git" (you can see it here: https://github.com/lucasoshiro/oshit)
I'll just chime in with congrats on the new book. I was a huge fan of the Network Programming book that I first read in 2013, and which I still consider as having the best balance of approachability and rigor. Looking forward to checking the new one out. :)
Thank you for your diligence in explaining complicated topics in a way that makes them accessible to people trying to learn what people before them figured out. You are a true educator that seems have found a place to support you to continue doing that.
Are you concerned that your git exposition is much longer than the other guides you have produced?
I've been looking for something to give to the students in my 3rd-year undergrad course. I had high hopes when saw the title, but this isn't it - it's immense and I don't think anyone will read it.
However I'm seriously thinking about patching something together by grabbing appropriate bits of this.
As a cloud security analyst that is thinking of going back to coding or DevSecOps, if I'm honest with myself, there is nothing new here that I have not seen before... (This is not a criticism or anything. If anything the problem is myself: if I can allocate time to learn this or use Anki to retain this).
Happy to see `git switch` mentioned, I've been trying to use it. The error message with the helpful advice on how to get it to check out headless tags and commits I hadn't seen before though - I'd been falling back to `checkout` for those cases.
I feel like a lot of the problems with Git UI come from needing to interact with a "normal" filesystem. I'd much rather have a FUSE/9p mount with all commits, index, etc. available as directories, where they can be read, written, diffed, etc.
Just discovered this all for the first time, and these guides are incredible! I've downloaded the GIT and networking ones. The humour is the best. I wish all textbooks were filled with jokes...
Looks amazing. I don't see anything on Large File Support though. As annoying as it is, it's a hard requirement for some parts of the industry (especially games) and worth a mention.
i feel that the big problem with git is how it applies names to procedures that are MUCH easier to understand unnamed. you can have a model of the current repo state, and the state you wish to reach. instead of just coding this difference on the data structure level, as imperative statements or functional expressions, we’re forced to translate them into a sequence of weird names and flags representing conversions into intermediate states.
Hey Beej, can you talk about what tool you use to create your guides? I'm assuming something like pandoc is involved for supporting your various formats?
It's great to see more git documentation, and I have a lot of respect for Beej's Guide to Network Programming. However he really needs to work on his commit hygiene. I get that this is a one-man project, but still it's pretty atrocious: https://github.com/beejjorgensen/bggit/commits/main/. This does not set a good example.
beej71|1 year ago
Love, Beej
aidos|1 year ago
raju|1 year ago
Section 5.1 (https://beej.us/guide/bggit/html/split/branches-and-fast-for...)
> The default branch is called main.
> The default branch used to be called master, and still is called that in some older repos.
This is not true. Git still defaults to `master`, but allows you to change the default (for future `git init` invocations via `git config --global init.defaultBranch <name>`)
See https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
Again, thank you. If I find anything else, I will be sure to post here.
*Update*: I also feel that referring to "older repos" sends the wrong message. *GitHub* decided to make this change, causing others to follow, and finally Git itself allows for the aforementioned configuration, but it has little to do with _newer_ or _older_, but rather preference.
junebash|1 year ago
unstuck3958|1 year ago
patchd|1 year ago
alberth|1 year ago
Thanks for all your guides over the years. Truly invaluable.
VierScar|1 year ago
1propionyl|1 year ago
Appreciate the work! Neat to see you still writing pieces like this all these years later!
jdmoreira|1 year ago
yrotslluf|1 year ago
There are two things I suggest as workflows for people when I teach them about rebase workflows.
> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...
For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.
For instance, if forked from main:
Squash all of those, and then as usual: Second, when rebasing repeatedly onto an evolving branch over time, you'll often find yourself resolving the same merge conflicts over and over again."rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time.
My gitconfig for these:
fabiensanglard|1 year ago
frogsRnice|1 year ago
Without your tutorials I’m not even sure if I would have chosen the carreer I did- thank you for all the love and effort you put into your posts; Im sure that there are many other people who you’ve touched in a similar way
JetSetIlly|1 year ago
I'm delighted to see that you're still active and still producing guides. Well done!
danw1979|1 year ago
Along with many others here, your network programming guide helped me so much back in the early days of my education and career. So thanks for that too…
chr86|1 year ago
So in figure 5.4 you say we merge 2 commits into a new one and somehow both branches point to new commit. This will definitely confuse people new to git.
I'd say it's better to write we merge anotherBranch into someBranch and leave the former where it is. Same for the next merge.
Just a suggestion
defanor|1 year ago
> But in this section we’re going to be talking about a specific kind of merge: the fast-forward. This occurs when the branch you’re merging from is a direct ancestor of the branch you’re merging into.
Looks like "from" and "into" are swapped: "main" is "into" there, "newbranch" is "from", and "main" is a direct ancestor of "newbranch".
bassp|1 year ago
chr86|1 year ago
In 9.4 there's no way reallinux/master points to same commit as master after the merge. It will still be where it was, one commit behind.
fphilipe|1 year ago
tvaughan|1 year ago
woodrowbarlow|1 year ago
in my experience, strong writing and communication skills are one of the best ways to stand out as an engineer -- and your articles are maybe the best example of this out there. keep on setting a great example for us. :)
manaskarekar|1 year ago
ZoomZoomZoom|1 year ago
greyw|1 year ago
xbar|1 year ago
I will be forever grateful for your work and its improvements of my life.
criddell|1 year ago
inlart|1 year ago
chanux|1 year ago
ස්තුතියි
iamthejuan|1 year ago
kali_00|1 year ago
"Let's say you modified foo.txt but didn't add it. You could: <git command>"
Followed by:
"And that would add it and make the commit. You can only do this with files you added before."
Wait, what? So, I modified foo.txt but didn't add it, and then the command to add and commit at the same time can only be done with files I did add before?
Guide was working great to heal years of git trauma up until that point though!
pkage|1 year ago
[0] https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/
nektro|1 year ago
soseng|1 year ago
riffraff|1 year ago
tathagatadg|1 year ago
Thank you Beej.
1propionyl|1 year ago
(I didn't read the IPC guide.)
randstring|1 year ago
matt3210|1 year ago
Sxubas|1 year ago
I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old.
To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language.
More on topic, this guide would've been super useful when I was learning. It is really easy to follow and covers common FAQs.
I fondly remember being intimidated by my first merge conflict, aborting it and just doing some workarounds to prevent the conflict.
Rendello|1 year ago
Here's, respectively, a discussion from 2021, and a discussion from a few weeks ago. In the latter, it's brought up that `git switch` is still considered experimental by the docs:
https://news.ycombinator.com/item?id=28024972
https://news.ycombinator.com/item?id=42649858
diggan|1 year ago
I don't think "git checkout" is considered the "old alternative", at least not yet. Last time I checked, `switch` is still experimental, I haven't even considered moving away from the workflows/commands I first learned when I picked up Git ~15 years ago. Everything I want to do still works exactly the same (`git checkout` still does the exact same stuff as before), and I'm able to collaborate with everyone else using git, why change workflow then?
scrapcode|1 year ago
juped|1 year ago
ajross|1 year ago
Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index is a tiny proto-commit still in progress that you "add" to before committing.
There. That's git. Want to know more? Don't read the guide, just google "how to I switch to a specific git commit without affecting my tree?", or "how do I commit only some of my changed files?", or "how to I copy this commit from another place into my current tree?".
The base abstractions are minimalist and easy. The things you want to do with them are elaborate and complicated. Learn the former, google the latter. Don't read guides.
ggregoire|1 year ago
1. git clone
2. git checkout
3. git pull
4. git add + commit + push
5. git reset / rebase
macjohnmcc|1 year ago
verandaguy|1 year ago
Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts.
Git plumbing's definitely a bit more obscure, and does a bunch of stuff on its own that you can't always easily do with porcelain commands because they're optimized for the common use cases.
TL;DR: while Git's big (huge even), a lot of what it provides is way off the beaten path for most devs.
20k|1 year ago
Learning git like this is honestly just hampering yourself
dijit|1 year ago
I am aware that beej's guides are typically quite comprehensive, but the vast nuances of git truly eluded me until this.
I guess Jujitsu would wind up being a much slimmer guide, or at least one that would be discoverable largely by humans?
beej71|1 year ago
And on that note, I feel like the guide covers maybe 10% of Git :), but hopefully 90% of common usage.
nomilk|1 year ago
vvpan|1 year ago
elevatedastalt|1 year ago
We have a basic Git cookbook we share with any new joinees so that they start committing code, but most of them just follow it religiously and don't understand what's going on (unsurprisingly).
However, literally everyone who attends the course comes out with a reasonable working understanding of Git so that they know what's actually happening.
That does NOT mean that they know all the commands well, but those can be trivially Googled. As long as your mental model is right, the commands are not a big deal. And yet, the vast majority of the discussion on HN on every single Git post is about the command line.
Funnily enough the class sounds a lot like the alt text of https://xkcd.com/1597/ (Just think of branches as...), the difference is that that is unironically the right way to teach Git to a technical audience, and they will come out with a fundamental understanding of it that they will never forget.
I honestly think it's such a high ROI time investment that it's silly to not do it.
lucasoshiro|1 year ago
sundarurfriend|1 year ago
A priori, I would have assumed this was one of those "just understand how every layer and every part of Linux works, and using Linux is easy" type arguments people used to make in the 90s - i.e. theoretically true, practically infeasible for most people.
Thankfully, I was lucky enough to come across a video explaining (some of) the git internal model early on, and it really doesn't take that much or that deep a knowledge of the internals for it to make a big difference. I'd say I know maybe 5% of how git works, and that already gave me a much better understanding of what the commands do and how to use them.
AnonHP|1 year ago
Does the course material (and perhaps any recordings) have any proprietary information or constraints to prevent you from sharing it publicly? Is this based on something that’s publicly available yet concise enough to fit within two hours? If yes, please share (perhaps in this thread and as a post submission on HN).
I’m asking because I believe that there can never be enough variety of training materials that handle a topic with different assumptions, analogies, focus, etc.
nomilk|1 year ago
valenterry|1 year ago
BeetleB|1 year ago
globular-toast|1 year ago
That is, to set your upstream branch to the branch you want to merge into, aka the integration branch. So instead of setting upstream of "feature/foo" to "origin/feature/foo", you would set it to "master" or "origin/master".
This simplifies a lot of things. When you run `git status` it will now tell you how far you have diverged from the integration branch, which is useful. When you run `git rebase` (without any arguments), it will just rebase you on to upstream.
Setting `origin/feature/foo` to upstream is less useful. Developers tend to "own" their branches on the remote too, so it's completely irrelevant to know if you've diverged from it and you'll never want to rebase there.
If you set `push.default` to "current", then `git push` will do what you expect too, namely push `feature/foo` to `origin/feature/foo`.
Why isn't this a more common setup?
ptx|1 year ago
Also, reusing branches for GitHub pull requests (vs. creating new branches for each PR) might warrant some discussion in section 17?
leonseled|1 year ago
dcchambers|1 year ago
Keep on fighting the good fight, Beej.
zeroq|1 year ago
On one hand you have the ideal world scenario when each and every change is granular and you can annotate and blame every single line of code with description. On the other hand you have a real world where teams are encouraged to squash changes so that every commit corresponds to a business requirement and you have to engage a whole cabal to smuggle a refactor.
A long time ago I've implemented a routine to use both SVN and GIT, so that I could use GIT on file save, and SVN on feature release. I think it was inspired by Eclipse workflow. Definitely not something I would recommend these days.
wodenokoto|1 year ago
I find it hard to judge when things are in a good enough state to commit and especially good enough to have a title.
I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function. Snapshot works pretty well for that, but got isn’t really centered around snapshots and doing good snapshots is not straightforward, at least to me.
What do you guys do?
MrJohz|1 year ago
It has this idea of mutable commits, so essentially you can check out a commit, and then whenever you change a file, the commit is updated with the new file contents. Then internally, whenever a commit gets changed (or any aspect of the repository) that gets recorded in an append-only log. At any point in time, you can scroll through that log and restore any previous repository state, including changes to individual files.
By default, Jujutsu does the snapshotting thing (i.e. updating the commit with the contents of the local files) every time you run the `jj` command. However, you can set up file watchers so that it does the snapshotting every time a file changes in the repository. If you do this, you should be able to browse through the op log and see all of the changes you've made over time, including reverting to any of those stages when necessary.
In fairness, I've not tried the file watcher thing out personally, but being able to review the op log is fantastic for trying to go back to previous versions of your repository without having to do teeny-tiny "wip" commits manually all the time.
shandor|1 year ago
Stop worrying about titles and content and commit to your heart’s content.
When ready, restructure those snapshots into a coherent story you want to tell others by squashing commits and giving the remaining ones proper titles and commit messages. I use interactive rebase for that, but there are probably other ways too.
foobarbaz33|1 year ago
Work in a feature branch. Commit often. Squash away the junk commits at the end.
> ...and especially good enough to have a title.
Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor.
I treat commits in a private branch the same as the undo log of the text editor. No one cares about the undo log of your editor as they never see it. The same should be true of your private feature branch commits. They are squashed away never to be seen by human eyes again.
jeroenhd|1 year ago
And then when everything works, compress commits into a few big commits with squash, and actually try to merge that back into the main branch.
> I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function.
For me, that would easily be three commits in my dev branch (one with a first implementation of the function, one with a refactor to a class, then another one back to a single function) and when the function is finished, one squashed commit in a merge request. If everything goes right, it's as if the class file was never there.
It has to be said, relying on squashing doesn't work well when you're working in a team that doesn't pay too close attention to merge requests (accidentally merging the many tiny commits). You also have to be careful not to squash over merges/use rebase wherever possible so your squashed commits don't become huge conflicts during merge trains.
When I work on my own stuff that I don't share, I don't bother squashing and just write tons of tiny commits. Half of them leave the code in a non-compiling state but I don't necessarily care, I use them as reference points before I try something that I'm not sure works.
There is something to be said for carefully picking commit points, though. While finding the source of a bug, git becomes incredibly powerful when you can work git bisect right, and for that you need a combination of granularity and precision. Every commit needs to have fully working code, but every commit should also only contain minimal changes. If you can find that balance, you can find the exact moment a bug was introduced in a program within minutes, even if that program is half a decade old. It rarely works perfectly, but when it does, it's a magical troubleshooting tool.
talles|1 year ago
jjice|1 year ago
Edit: Does anyone know a good way to convert one of the HTML pages into an epub for reading on an ereader? The PDFs will definitely work, but wanted to see if anyone knew of any tools for HTML -> EPUB conversion.
lucasoshiro|1 year ago
Try downloading the single-page html and coverting with pandoc:
pandoc index.html -o bla.epub
Maybe it needs some fine tuning, but the result seems good to me.
rco8786|1 year ago
It's also this sort of work that's becoming less necessary with AI, for better or worse. This appears to be a crazy good guide, but I bet asking e.g. Claude to teach you about git (specific concepts or generate the whole guide outline and go wide on it) would be at least as good.
yoyohello13|1 year ago
I also think if you are at the “don’t know what you don’t know” point of learning a topic it’s very hard to direct an AI to generate comprehensive learning material.
usefulcat|1 year ago
beej71|1 year ago
namaria|1 year ago
Wild.
kevinqi|1 year ago
dekhn|1 year ago
Anyway, the comment I really wanted to make was that I tried git lfs for the first time. I downloaded 44TB (https://huggingface.co/datasets/HuggingFaceFW/fineweb/tree/m...) over 3-4 days which was pretty impressive until I noticed that it seems to double disk space (90TB total). I did a little reading just to confirm it, and even learned a new term "git smudge". double disk space isn't an issue, except when you're using git to download terabytes.
jeroenhd|1 year ago
I know programmers like everything to be in version control, but AI models and git just aren't compatible.
boneitis|1 year ago
Branching, making commits, and creating pull requests come easy, but beyond that, I know utterly nothing about it.
lucasoshiro|1 year ago
I strongly suggest reading Pro Git, the official Git book by Scott Chacon and Ben Straub, available for free here: https://git-scm.com/book/en/v2.
I find it very pleasant to read and it really changed my perspective not only about Git but about how to write code in general. You don't need to read it entirely, but suggest at least these sections:
- 1.3 Getting Started - What is Git?: explains a little about snapshots and the three states
- 10.1 ~ 10.3 Plumbing and Porcelain, Git Objects and Git References: this explains Git in its lowest level, which is surprisingly simple but powerful. Those sections were enough for me to write my own "Git" (you can see it here: https://github.com/lucasoshiro/oshit)
beej71|1 year ago
smiljo|1 year ago
keithalewis|1 year ago
Are you concerned that your git exposition is much longer than the other guides you have produced?
password4321|1 year ago
Jujutsu VCS: Introduction and patterns
https://news.ycombinator.com/item?id=42934427
mshekow|1 year ago
I've also written a guide, targeting devs with basic Git experience. It is much shorter, maybe you or your team can benefit from it [1]
[1] https://www.augmentedmind.de/2024/04/07/ultimate-git-guide-f...
zabzonk|1 year ago
capitainenemo|1 year ago
https://heptapod.net/
https://docs.imfreedom.org/hgkeeper/
tombert|1 year ago
pjdesno|1 year ago
However I'm seriously thinking about patching something together by grabbing appropriate bits of this.
locusofself|1 year ago
PandaRider|1 year ago
As a cloud security analyst that is thinking of going back to coding or DevSecOps, if I'm honest with myself, there is nothing new here that I have not seen before... (This is not a criticism or anything. If anything the problem is myself: if I can allocate time to learn this or use Anki to retain this).
Pxtl|1 year ago
PhilipRoman|1 year ago
thomaslynch248|1 year ago
jayd16|1 year ago
ulbu|1 year ago
ghilston|1 year ago
curt15|1 year ago
Superbowl5889|1 year ago
ChrisMarshallNY|1 year ago
Thanks!
I’ve been using Git for years, but I bet that I’ll learn something from this.
yapyap|1 year ago
Eragonbro|1 year ago
Thanks for a lot for publishing Beej.
mgulick|1 year ago
I usually refer people to https://cbea.ms/git-commit/.
wunderlust|1 year ago
beej71|1 year ago
At least, that's why I'm in it. That, and to do my best to help students succeed.
hslee16|1 year ago
lprd|1 year ago
whatever1|1 year ago
matt3210|1 year ago
enahs-sf|1 year ago
abhimanyu81026|1 year ago
vanous|1 year ago
¯\_(ツ)_/¯
208 mentions of GitHub.
4 mentions of Gitea.
3 mentions of GitLab.
Why is it so biased and why is it helping to continue to teach people to centralized git.
mehulashah|1 year ago
aero-glide2|1 year ago