Part 1 · 1 chapters · ~8 min

Merges, Rebases and History Surgery

Three-way merges and merge bases, conflicts and how to read them, fast-forward versus merge commits, rebase and interactive rebase (squash, fixup, reword, reorder), cherry-pick and revert, reset modes, bisect run, the reflog and recovering lost work, force-with-lease, and team conventions (squash merge, linear history).

Rewrite safely, recover anything

code

git merge-base main feature                   # the common ancestor a three-way merge compares against
git rebase -i main                            # pick / squash / fixup / reword / drop, in an editor
git commit --fixup=a1b2c3d && git rebase -i --autosquash main     # fold a fix into an earlier commit
git push --force-with-lease                   # refuses if someone else pushed since you last fetched

git bisect start HEAD v1.41.0                 # bad, then good
git bisect run npm test -- transfers          # git checks out midpoints and runs the test: ~log2(n) steps
git bisect reset

# "I lost my commits"
git reflog                                    # HEAD@{3}: rebase (start): checkout main …
git reset --hard HEAD@{4}                     # back to before the rebase
git revert a1b2c3d                            # undo a published commit with a new commit (safe on shared branches)

Reading conflicts: with git config merge.conflictStyle zdiff3, conflict markers also show the merge-base version, so you can see what each side changed rather than guessing.

MERGE, REBASE AND RECOVERY

what each command does to the commit graph

swipe the figure sideways, or tap expand for full screen

1/4

merge vs rebase

Merging preserves what happened, including parallel work; rebasing rewrites your commits onto main so history reads linearly. Rebase only commits nobody else has pulled.

preserve vs rewritenever rebase shared history