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.
Git Branches: Intuition and Reality
21–30 of 281 posts
Re: Git Branches: Intuition and Reality
#22> in general, even if people’s intuition about a topic is technically incorrect in some ways, people usually have the intuition they do for very legitimate reasons! This is worth an essay of its own.
I'm still missing what part of the intuition is incorrect? It seems like the only "incorrectness" is that there's no explicit hierarchy of branches. Except that's wrong the HEAD ref points to the default branch. Any other branches are of equal significance, though.
Intuition would be that the branch starts at the point that it diverges from main, labeled “base” in the first diagram. In reality, the first commit in “main” and “branch” are the same commit.
Intuition likely comes from how a tree (fir or oak, not binary) is structured. Generally a branch starts at the trunk or some other branch, not at the ground where the trunk gives way to roots.
Re: Git Branches: Intuition and Reality
#23That's an excellent explanation.
> “Wrong” models can be super useful.
This is used in usability and UX design a lot. Affording mental models that don't reflect the actual code, happens all the time.
Re: Git Branches: Intuition and Reality
#24I cannot be the only one that gets away with only knowing: git pull git merge x git checkout [-b] foo git commit git push
To cleanup the history before asking for a review.
git rebase HEAD~2 -i
git commit —amend
Re: Git Branches: Intuition and Reality
#25> You do need to explicitly specify the other branch when merging or rebasing or making a pull request (like git rebase main), because git doesn’t know what branch you think your offshoot is based on.
I think a big issue with the presented intuition is that it's limited to wanting to merge the base/trunk/main branch into your feature branch. However, sometimes you want to merge a feature branch into another feature branch. With this in mind, you can form a better intuition, imo, where it's absolutely clear that you have to specify what branch you want to merge into another one.
Re: Git Branches: Intuition and Reality
#26I cannot be the only one that gets away with only knowing: git pull git merge x git checkout [-b] foo git commit git push
For me, git becomes unintelligible when there's a crazy train-track map of branching and merging.
So I usually do whatever I can to keep a single straight-line master history.
I branch off for a task, then after a while my branch isn't joined at the tip of master. So I rebase locally until it is. Then when the PR happens, master gets my changes added to the top, with no extra noise from merge commits.
Even if the local-rebase workflow is slightly more complicated, the payoff is a really clean history, making future reasoning about branches much easier. Not to mention merge conflicts are easier to solve when you rebase early & often.
Re: Git Branches: Intuition and Reality
#27> in general, even if people’s intuition about a topic is technically incorrect in some ways, people usually have the intuition they do for very legitimate reasons! This is worth an essay of its own.
I guess.
To me, the opposite is a more worthy essay: why, with all the power to customize our tech, do we create things that consistently work differently than people's intuition?
The fact that it "mostly jibes" feels like a footgun, not a feature.
I get that for some, "git just works! It made sense from day one" but in my limited experience, 0% of people I've worked with have said that.
Sure, we can all learn the tech. And expert techniques in any field often don't jibe with naive expectations. But for me and the folks I work with, the tech industry feels like it's gliding more towards inscrutible tools vs ease of use.
We've hit a stage where many rely on code completion bots and answer-supplying bots instead of being able to directly embrace our tech. I wish the tech was more approachable on its own, but perhaps this is the natural evolution of things.
Re: Git Branches: Intuition and Reality
#28> in general, even if people’s intuition about a topic is technically incorrect in some ways, people usually have the intuition they do for very legitimate reasons! This is worth an essay of its own.
Yup. If it works, it ain't stupid.
Re: Git Branches: Intuition and Reality
#29I have found that git makes a lot more sense if you reverse the mental model of lineage. People think about a lineage going forward. But a more useful way to think is in terms of backward pointers.
A commit points to it's parent(s). Since a branch is just a commit ID, you can follow the parent links backwards to find the whole history of that branch.
So a "branch point" is just where two chains of parent links converge.
The special part are merge commits. Those have multiple parents, indicating that two histories fused into one.
Re: Git Branches: Intuition and Reality
#30> in general, even if people’s intuition about a topic is technically incorrect in some ways, people usually have the intuition they do for very legitimate reasons! This is worth an essay of its own.
I'm still missing what part of the intuition is incorrect? It seems like the only "incorrectness" is that there's no explicit hierarchy of branches. Except that's wrong the HEAD ref points to the default branch. Any other branches are of equal significance, though.
No, the HEAD ref points to whatever branch is "active", that's how the active branch is defined. Indeed `git checkout branchname` does nothing except make HEAD point to the commit that `refs/heads/branchname` points to.
The intuition jvns meant is the idea that a branch only constitutes the commits since the point of divergence, but every branch actually contains the full history up to the root of its tree, and `git log` of course shows that. (If you want to only show the commits specific to a branch, you can do `git log parent..branch`. Note also that two branches need not have any common history, it's perfectly possible for a git graph to be disconnected.)