Lessons · Git · merge or replay when you pull
Merge or replay, when you pull
Plain pull merges their work into yours and leaves a merge commit. pull --rebase replays your commits on top of theirs and leaves a straight line.
Hone is a place to practise programming. This is one of its lessons, written out in full and free to read without an account.
What it is for
Same end content, different history. One of them puts a branch-and-join in the graph for a change nobody chose to branch for.
How to think about it
Rebase your own unpushed work; merge when the branch is shared. And expect a rebase to stop once per commit that conflicts, not once per pull.
Worked example
git fetch -q originTheir commit is now here, on origin/main.
git log --oneline --graph --allTwo lines that split at base: this is what diverged looks like.
git pull -q --rebase origin mainYour commit is rebuilt on top of theirs.
git log --oneline --graphOne line. No merge commit.
git log -1 --format=%pOne parent -- their commit. A merge would have shown two.
Your turn
Pull their work and replay yours on top instead of merging.
git pull origin main
Try it in a real repository
The trap
Rebasing commits other people already have. Replaying gives them new hashes, which is the same problem as force-pushing wearing a different hat.