Beej's Guide to Git

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :)

Love, Beej

Loved your Network programming guide :) !

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!

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!

I really appreciate you offering the content as a single page.

Thanks for all your guides over the years. Truly invaluable.

Your network programming guide really saved my bacon back when I was taking a networking class, I appreciate all your hard work!

I am just happy and thankful that people like you exists.

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!

I read your guide to C programming as a teen, and as a firmware dev today I'm forever indebted to you.

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.

Thank you for this Beej!

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…

Doing Chico proud!

There's an issue for the IPC guide on GitHub that's almost a year old with zero reaction.

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

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!

This is a fantastic mention! I've been commenting out my commit message lines and then saving as a way to trigger this. Feeling like a caveman...

Beej you are a legend. We all love you! You were a beacon of light for us in the 90s

Thank you.

I will be forever grateful for your work and its improvements of my life.

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.

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. :)

I just love nuggets like this. I've been using VIM for 26 years and git for about 15. I never knew about adding c. I've always felt that :q! should exit with a non-zero status code, at least if no :w had been made.

I usually use :q! which seems to do the same thing

Thanks for your great guides. Helped me a lot during my career (so far) :)

What's the difference between the one- and two-sided pdfs?

Thank you legend!

ස්තුතියි

Layout for printing (on paper, for those who still do that) I presume.

TIL! The funny thing about Vim is that you can have used vi/Vim for 30+ years and still learn new things. I'll add this to the Vim appendix. Cheers!

Same!

I was on the fence about this one. Yes, it's totally useful, but I swore after writing my comprehensive C guide I would never write a comprehensive guide again. :) So I try to decide where to cut people loose to use other resources once they have the foundation.

All that said, they are really useful. And, honestly, the chapter would be pretty short to get basic usage down... but also if you've gotten as far as grokking how branches work, it's pretty easy to pick up worktrees. The fact that lots of people don't know they exist is points for adding it just for that reason alone.

I'll mull it over. :) Cheers!

Exactly this. There are three main differences:

1. The margins are offset in two-sided, alternating pages. 2. The page numbers are justified alternately left and right in two-sided, and the page header differs left and right. 3. Sometimes a blank page is injected with two-sided to make a chapter start on the correct side of the book.

Great guide. Figure 6.1, 6.2 and 6.3 are missing commit “6”.

First followed you on flickr ages ago, then your networking guide! Thanks for the amazing resources.

The minor difference is that :q! quits without saving but returns zero as the exit code, but :cq quits with a nonzero exit code. Git interprets the nonzero exit code as "editing failed", following the Unix convention that zero means success. If you didn't save the commit message while working on it, :q! will send the empty template back to Git, which Git is smart enough to not commit. But if you accidentally save your work partway through, :q! will still commit the message you wanted to abandon.

It is the same with Git

Interesting I’ve always just deleted the contents of the entire buffer and :wq to cause a failure due to lack of message

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.

"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:

    [alias]
     forked = "!f() { git merge-base $1 --fork-point; }; f"
     squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f"
    [rerere]
     enabled = true

Not wrong, but one thing I did not spot in all the great explanations related to HEAD is that @ is an alias for HEAD that is a lot easier to type.

Mnemonic to help remember: cancel quit

In section 5.7:

> 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".

Guilty as changed your honour

If you have been using git for 30+ years, you need to take me to your time machine. It turns 20 this year.

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

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.

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.

Guilty as UNchanged*

That only works if the edit buffer is blank or only has commented out lines. In other cases, such as when you're trying to cancel a `git commit --amend` that loads up the last commit message in your buffer, :q! will not cancel the commit, but :cq will.

Hrm. I didn't realize. I unset `init.defaultbranch` and it uses `master` and prints a block of hints.

> hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and 'development'. The just-created branch can be renamed via this command:

That's going to make it more "interesting" to write the fix, that's for sure.

Thanks!

You're welcome! :)

D'oh! Fixed.

I wouldn't have put it there because I didn't know that. What the hell... LOL Now that's a hilarous thing to get through a book not knowing.

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.

Just a suggestion

Ok, so unless I'm missing something, this is a big error.

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.

Yeah, I was speaking a little fast and loose here since this was just the intro part. I was worried that it would actually be more confusing to say that we merged them and they pointed to different places... which is of course what actually happens.

Let me see if I can do that and save the clarity.

That's my lowest traction guide, I think, not counting Beej's Guide to Killing Dragons. :)

I've fixed it, and wrote a quick script to list all issues and PRs on all my books so they don't fall through the cracks.

Yeah... so re-reading that, I don't know what I was thinking. Uploading a rewrite of that bad crap now.

:cq is useful in a shell loop that compares two directory trees that invokes vim to let you see what's changed in every file that's different. I use it often:

    ((cd /tmp/t; find . -type f -print) | sort | while read f; do cmp -s {/tmp/t,/tmp/t1}/$f || vim -f -d {/tmp/t,/tmp/x1}/$f 0<&9 || break; done) 9<&0

Typing ^C to vim doesn't get you very far, so if you make a mistake causing the loop to return 1000's of files you are in for a bit of pain without :cq. The :cq triggers the break, exiting the loop.

Thanks!