20 ms·

Beej's Guide to Git

1062 points by mixto 2y ago

tombert 2y ago
The Beej books are awesome. I remember reading these and watching the 3DBuzz video tutorials when I was first learning how to program.
pkage 2y ago
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. [0] https://beej.us/guide/bgnet/ https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/ https://beej.us/guide/bggit/
- 1propionyl 2y ago
  +1, I have almost exactly the same story! (I didn't read the IPC guide.)
- nektro 2y ago
  [1] https://beej.us/guide/bgipc/ https://beej.us/guide/bgipc/
  - pkage 2y ago
    mispasted, thanks!
- soseng 2y ago
  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!
- matt3210 2y ago
  I had no idea about IPC! I better go read it!
- riffraff 2y ago
  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.
- randstring 2y ago
  Indeed, my first steps in network programming years ago were with the help of this excellent guide.
- tathagatadg 2y ago
  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! Thank you Beej.
dijit 2y ago
Well, what's terrifying is that the guide is so long. 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?
- vvpan 2y ago
  It tells me that git is the wrong tool for the majority of people but it just happened to stick.
  - stephen_g 2y ago
    I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.
    - riffraff 2y ago
      Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning. Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs. Compare git diff with hg diff for example.
      - account42 2y ago
        I've never been confused by git checkout. git checkout <branch> switches to a branch. git checkout <commit> switches to a commit in a detached head state. git checkout <file> switches just the content of a file. You can also combine these ofc but it all works pretty much as expected. The -b switch for creating new branches is someting you need to look up once and then just remember - and it does make sense - you are switching to a new branch.
PandaRider 2y ago
Initial impressions: Looks great. 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).
matt3210 2y ago
Wowza a new Beej guide!
rco8786 2y ago
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.
- yoyohello13 2y ago
  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.
  - rco8786 2y ago
    Definitely more efficient in terms of power consumed, not so in terms of human effort to build such guides across nearly every topic one could think of. But you're right, we shouldn't ignore the power consumption. I have found that asking AI "You are an expert teacher in X. I'd like to learn about X, where should I start?" is actually wildly effective.
    - yoyohello13 2y ago
      > not so in terms of human effort to build such guides across nearly every topic How will LLMs be trained if no humans are making learning materials?
      - rco8786 2y ago
        Whoever, or whatever, is creating the thing that needs reference materials would have to seed the initial set (just as they/it seeded the thing itself) and then go from there. If you didn't, then you won't be included the training set (obviously) and the AI would not easily know about you. Sort of how if you start a really cool company but don't make a website Google doesn't know about you and can't return you in their search results. It's valuable for Google (AI) to know about you, so it's valuable to build the sites (docs) to get indexed (trained on).
curt15 2y ago
I'm a fan of Beej's writing style.
boneitis 2y ago
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.
- lucasoshiro 2y ago
  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 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 https://github.com/lucasoshiro/oshit)
- beej71 2y ago
  If you do check it out and there are parts that are confusing, I'd love to hear about it.
  - at_a_remove 2y ago
    This is partially a question and the rest is shameful confession: I had haltingly used cvs as a solo programmer, and when I was suddenly no longer a solo programmer and had to use git, everything went haywire. I am an Old and we never were taught anything about coding with other people who were also working on the same project. I have had many successful projects but never with another person. With that as a background, does your guide cover things like: 1) Merging. I was told that merging happens "automagically" and I cannot, for the life of me, understand how a computer program manages to just ... blend two functions or whatever and it "works." Does your guide make sense of this? 2) Apparently there are holy wars (see also vi versus emacs) about the One True Way to ... decide on branches and whatnot. Are there pros and cons laid out anywhere? 3) Everything seems broken down into teensy tiny functions when I look at someone's git repository, just skillions of files all over the place. Is this a git thing, a code repository thing, or simply that, in order for multiple people to work on the same project, everything must be atomized and then reassembled later? What's your opinion?
Superbowl5889 2y ago
Always been delighted enjoyer of beejs guides specially python and networking
elevatedastalt 2y ago
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/ 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 2y ago
  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!
  - elevatedastalt 2y ago
    Exactly, and it's such a high success rate! This is precisely why it enrages me when all HN discussion about Git devolves to the same stuff about how it's complex and this and that. A technical person who has general sense about basic data structures (Leetcode nonsense not needed) can be taught Git in under 2 hours and they will retain this knowledge forever. If you can't invest that little time to learning a tool you will use everyday and instead will spend hours Googling and blindly copy-pasting Git commands, that's on you, not on Git.
scrapcode 2y ago
I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
- macjohnmcc 2y ago
  And still shoot yourself in the foot.
- verandaguy 2y ago
  Eh, yes and no. 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.
  - ujkiolp 2y ago
    not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible
    - sampullman 2y ago
      I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.
talles 2y ago
I love how there's a section for exiting vim
beej71 2y ago
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
- fabiensanglard 2y ago
  Loved your Network programming guide :) !
- 1propionyl 2y ago
  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!
- junebash 2y ago
  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!
  - beej71 2y ago
    You're welcome! :)
- alberth 2y ago
  I really appreciate you offering the content as a single page. Thanks for all your guides over the years. Truly invaluable.
- bassp 2y ago
  Your network programming guide really saved my bacon back when I was taking a networking class, I appreciate all your hard work!
- iamthejuan 2y ago
  I am just happy and thankful that people like you exists.
- 2y ago
password4321 2y ago
In case you missed it also on the front page Tuesday, 20+ anecdotes recommending a newer git-compatible VCS: Jujutsu VCS: Introduction and patterns https://news.ycombinator.com/item?id=42934427 https://news.ycombinator.com/item?id=42934427
ChrisMarshallNY 2y ago
Extremely well-written! Thanks! I’ve been using Git for years, but I bet that I’ll learn something from this.
leonseled 2y ago
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.
enahs-sf 2y ago
Wake up babe. A new Beej’s guide just dropped.
whatever1 2y ago
Wow 200 page guide on git.
yapyap 2y ago
Wow 200+ pages, will def have fun sifting thru this one. Thanks!
lprd 2y ago
A new Beej guide? In this economy!?
Sxubas 2y ago
> The Old Command: git checkout 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 2y ago
  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: https://news.ycombinator.com/item?id=28024972 https://news.ycombinator.com/item?id=28024972 https://news.ycombinator.com/item?id=42649858 https://news.ycombinator.com/item?id=42649858
- diggan 2y ago
  > 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?
  - RohMin 2y ago
    git switch focuses on switching branches while git checkout extends further than that
    - diggan 2y ago
      Right, so for the folks at home who already know and use `git checkout`, no switch needed (no pun intended) as everything already works fine and probably won't be deprecated in the near future.
dekhn 2y ago
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/main 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 2y ago
  Git is absolutely terrible for large files, especially binary files. That's why git LFS rarely ever uses git as a storage mechanism. I know programmers like everything to be in version control, but AI models and git just aren't compatible.
  - curiousinspo 2y ago
    [dead]
BeetleB 2y ago
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.
aero-glide2 2y ago
I just tell chatgpt what i want and it gives me a command to do it.
zabzonk 2y ago
I love the beej guides, and I'm OK with git, but I'm sad there isn't any really viable hosting for mercurial any more.
- capitainenemo 2y ago
  https://hg.sr.ht/ https://hg.sr.ht/ https://heptapod.net/ https://heptapod.net/ https://docs.imfreedom.org/hgkeeper/ https://docs.imfreedom.org/hgkeeper/
zeroq 2y ago
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.
vanous 2y ago
> GitHub is a web-based front-end to Git. ¯\_(ツ)_/¯ 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 2y ago
  It seems that Beej built this guide to help his students. More of them are probably using Git and GitHub in anger than the other tools.
wodenokoto 2y ago
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. What do you guys do?
- shandor 2y ago
  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.
- foobarbaz33 2y ago
  > 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.
  - jaapz 2y ago
    If I had 5 cents for every commit in a feature branch with the commit message "wip"...
    - foobarbaz33 2y ago
      You should have 0 cents. Squash and chill is the way to go.
dcchambers 2y ago
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. Keep on fighting the good fight, Beej.
wunderlust 2y ago
Why are there so many guides to git?
- beej71 2y ago
  Because it's challenging to use, and writing effectively about challenging-to-use things is a really fun challenge. At least, that's why I'm in it. That, and to do my best to help students succeed.
mshekow 2y ago
This guide looks really nice, targeting novice Git users. 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-for-developers/ https://www.augmentedmind.de/2024/04/07/ultimate-git-guide-f...
locusofself 2y ago
Something like 28 years ago I created my first TCP/IP sockets in C by reading one of Beej's tutorials. Thanks Beej!
PhilipRoman 2y ago
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.
thomaslynch248 2y ago
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...
ulbu 2y ago
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.
ghilston 2y ago
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?
globular-toast 2y ago
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`. Why isn't this a more common setup?
smiljo 2y ago
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. :)
Eragonbro 2y ago
Could you add dark mode for html please? Thanks for a lot for publishing Beej.
ptx 2y ago
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?
jayd16 2y ago
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.
jjice 2y ago
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.
- lucasoshiro 2y ago
  > Does anyone know a good way to convert one of the HTML pages into an epub for reading on an ereader? 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.
Pxtl 2y ago
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.
hslee16 2y ago
Amazing. Thank you very much Beej!
abhimanyu81026 2y ago
important - git learning
pjdesno 2y ago
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.
mgulick 2y ago
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/ https://github.com/beejjorgensen/bggit/commits/main/. This does not set a good example. I usually refer people to https://cbea.ms/git-commit/ https://cbea.ms/git-commit/.
keithalewis 2y ago
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?

1062 points by mixto 2y ago

The Beej books are awesome. I remember reading these and watching the 3DBuzz video tutorials when I was first learning how to program.

pkage 2y ago

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. [0] https://beej.us/guide/bgnet/ https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/ https://beej.us/guide/bggit/

1propionyl 2y ago
+1, I have almost exactly the same story! (I didn't read the IPC guide.)
nektro 2y ago
[1] https://beej.us/guide/bgipc/ https://beej.us/guide/bgipc/
- pkage 2y ago
  mispasted, thanks!
soseng 2y ago
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!
matt3210 2y ago
I had no idea about IPC! I better go read it!
riffraff 2y ago
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.
randstring 2y ago
Indeed, my first steps in network programming years ago were with the help of this excellent guide.
tathagatadg 2y ago
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! Thank you Beej.

dijit 2y ago

Well, what's terrifying is that the guide is so long. 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?

vvpan 2y ago
It tells me that git is the wrong tool for the majority of people but it just happened to stick.
- stephen_g 2y ago
  I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.
  - riffraff 2y ago
    Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning. Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs. Compare git diff with hg diff for example.
    - account42 2y ago
      I've never been confused by git checkout. git checkout <branch> switches to a branch. git checkout <commit> switches to a commit in a detached head state. git checkout <file> switches just the content of a file. You can also combine these ofc but it all works pretty much as expected. The -b switch for creating new branches is someting you need to look up once and then just remember - and it does make sense - you are switching to a new branch.

PandaRider 2y ago

Initial impressions: Looks great. 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).

matt3210 2y ago

Wowza a new Beej guide!

rco8786 2y ago

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.

yoyohello13 2y ago
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.
- rco8786 2y ago
  Definitely more efficient in terms of power consumed, not so in terms of human effort to build such guides across nearly every topic one could think of. But you're right, we shouldn't ignore the power consumption. I have found that asking AI "You are an expert teacher in X. I'd like to learn about X, where should I start?" is actually wildly effective.
  - yoyohello13 2y ago
    > not so in terms of human effort to build such guides across nearly every topic How will LLMs be trained if no humans are making learning materials?
    - rco8786 2y ago
      Whoever, or whatever, is creating the thing that needs reference materials would have to seed the initial set (just as they/it seeded the thing itself) and then go from there. If you didn't, then you won't be included the training set (obviously) and the AI would not easily know about you. Sort of how if you start a really cool company but don't make a website Google doesn't know about you and can't return you in their search results. It's valuable for Google (AI) to know about you, so it's valuable to build the sites (docs) to get indexed (trained on).

curt15 2y ago

I'm a fan of Beej's writing style.

boneitis 2y ago

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.

lucasoshiro 2y ago
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 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 https://github.com/lucasoshiro/oshit)
beej71 2y ago
If you do check it out and there are parts that are confusing, I'd love to hear about it.
- at_a_remove 2y ago
  This is partially a question and the rest is shameful confession: I had haltingly used cvs as a solo programmer, and when I was suddenly no longer a solo programmer and had to use git, everything went haywire. I am an Old and we never were taught anything about coding with other people who were also working on the same project. I have had many successful projects but never with another person. With that as a background, does your guide cover things like: 1) Merging. I was told that merging happens "automagically" and I cannot, for the life of me, understand how a computer program manages to just ... blend two functions or whatever and it "works." Does your guide make sense of this? 2) Apparently there are holy wars (see also vi versus emacs) about the One True Way to ... decide on branches and whatnot. Are there pros and cons laid out anywhere? 3) Everything seems broken down into teensy tiny functions when I look at someone's git repository, just skillions of files all over the place. Is this a git thing, a code repository thing, or simply that, in order for multiple people to work on the same project, everything must be atomized and then reassembled later? What's your opinion?

Superbowl5889 2y ago

Always been delighted enjoyer of beejs guides specially python and networking

elevatedastalt 2y ago

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/ 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 2y ago
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!
- elevatedastalt 2y ago
  Exactly, and it's such a high success rate! This is precisely why it enrages me when all HN discussion about Git devolves to the same stuff about how it's complex and this and that. A technical person who has general sense about basic data structures (Leetcode nonsense not needed) can be taught Git in under 2 hours and they will retain this knowledge forever. If you can't invest that little time to learning a tool you will use everyday and instead will spend hours Googling and blindly copy-pasting Git commands, that's on you, not on Git.

scrapcode 2y ago

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

macjohnmcc 2y ago
And still shoot yourself in the foot.
verandaguy 2y ago
Eh, yes and no. 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.
- ujkiolp 2y ago
  not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible
  - sampullman 2y ago
    I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.

talles 2y ago

I love how there's a section for exiting vim

beej71 2y ago

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

fabiensanglard 2y ago
Loved your Network programming guide :) !
1propionyl 2y ago
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!
junebash 2y ago
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!
- beej71 2y ago
  You're welcome! :)
alberth 2y ago
I really appreciate you offering the content as a single page. Thanks for all your guides over the years. Truly invaluable.
bassp 2y ago
Your network programming guide really saved my bacon back when I was taking a networking class, I appreciate all your hard work!
iamthejuan 2y ago
I am just happy and thankful that people like you exists.
2y ago

password4321 2y ago

In case you missed it also on the front page Tuesday, 20+ anecdotes recommending a newer git-compatible VCS: Jujutsu VCS: Introduction and patterns https://news.ycombinator.com/item?id=42934427 https://news.ycombinator.com/item?id=42934427

ChrisMarshallNY 2y ago

Extremely well-written! Thanks! I’ve been using Git for years, but I bet that I’ll learn something from this.

leonseled 2y ago

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.

enahs-sf 2y ago

Wake up babe. A new Beej’s guide just dropped.

whatever1 2y ago

Wow 200 page guide on git.

yapyap 2y ago

Wow 200+ pages, will def have fun sifting thru this one. Thanks!

lprd 2y ago

A new Beej guide? In this economy!?

Sxubas 2y ago

> The Old Command: git checkout 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 2y ago
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: https://news.ycombinator.com/item?id=28024972 https://news.ycombinator.com/item?id=28024972 https://news.ycombinator.com/item?id=42649858 https://news.ycombinator.com/item?id=42649858
diggan 2y ago
> 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?
- RohMin 2y ago
  git switch focuses on switching branches while git checkout extends further than that
  - diggan 2y ago
    Right, so for the folks at home who already know and use `git checkout`, no switch needed (no pun intended) as everything already works fine and probably won't be deprecated in the near future.

dekhn 2y ago

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/main 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 2y ago
Git is absolutely terrible for large files, especially binary files. That's why git LFS rarely ever uses git as a storage mechanism. I know programmers like everything to be in version control, but AI models and git just aren't compatible.
- curiousinspo 2y ago
  [dead]

BeetleB 2y ago

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.

aero-glide2 2y ago

I just tell chatgpt what i want and it gives me a command to do it.

zabzonk 2y ago

I love the beej guides, and I'm OK with git, but I'm sad there isn't any really viable hosting for mercurial any more.

capitainenemo 2y ago
https://hg.sr.ht/ https://hg.sr.ht/ https://heptapod.net/ https://heptapod.net/ https://docs.imfreedom.org/hgkeeper/ https://docs.imfreedom.org/hgkeeper/

zeroq 2y ago

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.

vanous 2y ago

> GitHub is a web-based front-end to Git. ¯\_(ツ)_/¯ 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 2y ago
It seems that Beej built this guide to help his students. More of them are probably using Git and GitHub in anger than the other tools.

wodenokoto 2y ago

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. What do you guys do?

shandor 2y ago
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.
foobarbaz33 2y ago
> 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.
- jaapz 2y ago
  If I had 5 cents for every commit in a feature branch with the commit message "wip"...
  - foobarbaz33 2y ago
    You should have 0 cents. Squash and chill is the way to go.

dcchambers 2y ago

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. Keep on fighting the good fight, Beej.

wunderlust 2y ago

Why are there so many guides to git?

beej71 2y ago
Because it's challenging to use, and writing effectively about challenging-to-use things is a really fun challenge. At least, that's why I'm in it. That, and to do my best to help students succeed.

mshekow 2y ago

This guide looks really nice, targeting novice Git users. 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-for-developers/ https://www.augmentedmind.de/2024/04/07/ultimate-git-guide-f...

locusofself 2y ago

Something like 28 years ago I created my first TCP/IP sockets in C by reading one of Beej's tutorials. Thanks Beej!

PhilipRoman 2y ago

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.

thomaslynch248 2y ago

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

ulbu 2y ago

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.

ghilston 2y ago

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?

globular-toast 2y ago

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`. Why isn't this a more common setup?

smiljo 2y ago

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

Eragonbro 2y ago

Could you add dark mode for html please? Thanks for a lot for publishing Beej.

ptx 2y ago

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?

jayd16 2y ago

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.

jjice 2y ago

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.

lucasoshiro 2y ago
> Does anyone know a good way to convert one of the HTML pages into an epub for reading on an ereader? 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.

Pxtl 2y ago

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.

hslee16 2y ago

Amazing. Thank you very much Beej!

abhimanyu81026 2y ago

important - git learning

pjdesno 2y ago

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.

mgulick 2y ago

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/ https://github.com/beejjorgensen/bggit/commits/main/. This does not set a good example. I usually refer people to https://cbea.ms/git-commit/ https://cbea.ms/git-commit/.

keithalewis 2y ago

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?