Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git Branches: Intuition and Reality

jvns.ca

Post reply on HN
Print view View original

171–180 of 281 posts

Re: Git Branches: Intuition and Reality

#171

Post by evntdrvn »

seba_dos1 wrote: post #99
tharkun__ wrote: post #96

Earlier quoted context omitted.

I keep repeating this every time someone talks about git and finds something weird or doesn't get branches, so I'm really glad your parent mentioned it as well and I know there's someone else out there that "gets" that: In git it's all just labels/pointers It's not useful at all to think about branches as the user sees them as "things" of their own. Branches don't "have" anything. Branches in that sense are just conv…

To make things more complicated, the word "tag" is also overloaded. It can either be just a reference (in git lingo, a "ref") to a commit - just like a branch, only differing from it in how the tools treat it; but they can also be "annotated tags" which are pointing to a special tag object which contains some metadata and only then points to a specific commit (or other kind of object...) :)

You’ll also see the first type referred to as “lightweight tags”, if that helps anyone :)

Re: Git Branches: Intuition and Reality

#172

Post by grodriguez100 »

lifeisstillgood wrote: post #161
layer8 wrote: post #59

Earlier quoted context omitted.

The issue is that if you consider a branch to be what is really the history of the branch tip, then a branch is not just the part starting from the last join with another branch. Instead it is some directed path through the commit DAG, a path that in general can’t be reconstructed from the information Git keeps. If, for example, you have a structure like | o / \ o o A | | B o o \ / o / \ o o C | | D o o \ / o | then…

Just to go off on a tangent - that's a pretty neat diagram for a throw away comment. was that just careful spacing in the HN textbox or did you use a tool - which one ? :-)

“Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)”

Looks like this also switches to a monospaced font, which makes it easier to draw ASCII art.

  This should be rendered using a monospaced font. 
  _____
  \   /
   \ /
    O

Re: Git Branches: Intuition and Reality

#173

Post by why-el »

I've learned only one constant with git in my years as a programmer: master your own employer's git use cases, and pray to god for three things:

1. you don't change places often and thus git patterns.

2. you don't accidentally ship and commit a multi-GB file to your remote.

3. you don't change the git process on yourself and your colleagues without an extremely solid reason.

Document your chosen git patterns, even in 2023.

Re: Git Branches: Intuition and Reality

#175

Post by taberiand »

k__ wrote: post #157

That article would have been a lot better if it showed illustrations for the "right" mental model too.

The right mental model is to realise the 'main' branch is only special by convention - git doesn't actually treat it differently from any other branch.

All of the confusion expressed in the article stems from a misunderstanding that main should work in some special way.

Of course every branch's history goes all the way back to root and not to some arbitrary common commit of another branch like 'main'. Of course rebase and merge can work "backwards" from main onto some branch (because it's not "backwards" because main is not special - it just isn't done much in practice because keeping main straight helps with collaboration)

Furthermore, by realising that main isn't inherently special, it becomes obvious that the actions can be done between any two branches as needed.

The right mental model is - it's just commits, all the way down.

Re: Git Branches: Intuition and Reality

#176

Post by pitaj »

MauranKilom wrote: post #60

I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash... How do you undo a merge that you didn't mean to do/did wrongly? git reset --hard Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature? git stash git checko…

> How do you undo a merge that you didn't mean to do/did wrongly?

I usually used `switch` for this:

    # Check out the previous commit
    git switch -d HEAD~
    # Overwrite the branch
    git switch -C

Re: Git Branches: Intuition and Reality

#177

Post by k__ »

taberiand wrote: post #175
k__ wrote: post #157

That article would have been a lot better if it showed illustrations for the "right" mental model too.

The right mental model is to realise the 'main' branch is only special by convention - git doesn't actually treat it differently from any other branch. All of the confusion expressed in the article stems from a misunderstanding that main should work in some special way. Of course every branch's history goes all the way back to root and not to some arbitrary common commit of another branch like 'main'. Of course rebas…

"All of the confusion expressed in the article stems from a misunderstanding that main should work in some special way."

I didn't have that impression when reading that article.

To me it seems that the confusion comes from thinking in actual branches, and not from thinking anything special about main.

Re: Git Branches: Intuition and Reality

#178

Post by hnarn »

cpeterso wrote: post #160
mr_mitm wrote: post #121

Earlier quoted context omitted.

When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)

Leaning into the tree metaphor (and following the precedent of other version control systems), git should have used the term trunk instead of master or main .

Why? That would heavily imply that master/main is somehow technically different from all other branches (since a trunk is certainly not a branch), which to my knowledge is not true.

Re: Git Branches: Intuition and Reality

#179

Post by Sharlin »

karatinversion wrote: post #148
Sharlin wrote: post #21

But... If you have a rebase workflow, then `git checkout trunk; git rebase branch` is exactly how you "merge" an offshoot branch into a trunk branch! That's what Github does when you rebase-merge a PR, for example.

No, that’s not right. If you did that, you would need to force push to get the result pushed to the remote.

Oh, right. So what actually happens is that the offshoot must first be rebased on top of the trunk, and then trunk can be fast-forward merged/rebased (same thing, really) to the offshoot's head.

Re: Git Branches: Intuition and Reality

#180

Post by hnarn »

alex_smart wrote: post #156
tremon wrote: post #140

Earlier quoted context omitted.

git reset --hard is actually dangerous, because it throws away local modifications that were not yet committed. To undo just the commit and not the work, you should use git reset --soft (to undo just the git commit) or git reset --mixed (to undo both the git commit and the "git add"s leading up to the commit).

git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.

That does not sound right at all, I’m pretty sure there’s a warning when you try to checkout a branch that would override local unstaged changes. I might be wrong but I’d like some proof.
Post reply on HN