Beej's Guide to Git

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)

If you do check it out and there are parts that are confusing, I'd love to hear about it.

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?

Jumping in on 3: This isn't a git thing, this is a "bad design" thing. I'm thinking it looks like a git thing because two things happened at the same time: git got popular right as there was a huge influx of juniors from a mix of bootcamps and being self-taught, who never learned how to architect their code.

1) I say it happens automagically. :) I'm not really familiar with merging strategies, but I would imagine that it happens in a way similar to a diff. But it only works if the changes are "distant" from one another. If they are happening too close in the file, Git punts and tells you there's a conflict you have to manually resolve.

2) I try to stay out of holy wars. Use the right tool for the job, I say, and sometimes that could even be Emacs. ;) I do talk about a few of the more common options for branching in teams (mostly focused on the small teams we tend to have here in university). And I talk about their pros and cons. But I stop short of declaring one the winner since the best option depends on the circumstances. IMHO.

3) I've seen repos with big functions and small functions, so I don't think it's a Git thing. Students tend to write functions that do too much and are too large, but it's certainly possible to break things down into pieces that are prohibitively tiny. Overall this seems more of a software engineering design choice than anything Git-related.

> 1) Merging.

It's really simple, much more than what we think at first. I explained it myself here, in section "three-way merge": https://lucasoshiro.github.io/posts-en/2022-03-12-merge-subm...

There are plenty of other explanations out there if mine isn't enough clear for you, just google "Three-way merge".

> blend two functions or whatever and it "works."

It's purely based on find changes and it doesn't check the syntax. If the commits has been merge correctly is responsibility of the programmer.

Look at this valid Python code:

if a == 1:

    foo()

    bar()

If a branch deletes foo() and other branch deletes bar(), it will merge to this invalid Python code:

if a == 1:

In Python we can't just leave empty blocks, like C or Java. In Python we would need to use "pass":

if a == 1: pass

So yeah, there are cases that merge doesn't work because Git operates over data, no matters too much what information they hold