Rebase! I totally git it now.
Both merge and rebase are commands I’ve used plenty, and read about a lot, without managing to wrap my head around wtf actually happens. But this week all became clear. 💪 It’s kinda ironic how tutorials with diagrams make sense first after you already understand something.
I leveled up now after asking someone to talk me through it. We had pen & paper — and a repo with multiple collaborators, but straightforward changes. This exercise helped identify what I was confused about in a way self study can’t. My git experience has mostly revolved around:
- working alone, often with a rather linear progress
- or collaborating, but with our changes on separate sets of files
- occasional merge conflicts, but that are easy to resolve
So I haven’t needed to understand this before: how does git magically handle so much complexity in a pull request, when it chokes on much simpler changes in a push to master?! And how do some people end up with messy merge conflicts that others seem to avoid?
We found out that I had not quite understood how commits relate to history. Now I know that every single commit always has a parent commit. Only the initial commit has no parent. And just like that, reading about fast-forward makes sooo much more sense.
git merge
- does not rewrite history
- requires merge commits that point to more than one parent
git rebase
- will rewrite history so use with care 👌
- moves a branch from one parent commit to a different parent commit
- I can use this to clean up local changes
Note to self — Concept that is hard to grasp? Discuss with people who understand them! Read up first to get a foundation, then ask for help when stuck. 🙏