Branching and Merging
Rules for branch management, merge strategies, and rebasing. The area where most Git
confusion lives.
Rating 5 — These Change Everything
Never Rebase Public/Shared Branches
Source: Git Project Management (Ch3.10), Advanced Git 2nd Ed (Ch4), Git for Teams (Ch3)
Statement: Rebasing rewrites commit history by creating new commits with new hashes. If you
rebase a branch that others have pulled, their copies will diverge from yours. Their next pull will
either fail or create duplicate commits. This applies to main, develop, and any shared feature
branch. Implication: Rebase freely on LOCAL, UNPUSHED branches. Never rebase anything
that has been pushed to a shared remote unless you've coordinated with every person who has
pulled it. The safe rule: rebase before push, merge after push. Rating: 5
Rebase to Keep Up-to-Date, Merge to Integrate Features
Source: Advanced Git 2nd Ed (Ch9), Git Project Management (Ch8.3), Git for Teams (Ch3)
Statement: Use git rebase main on your feature branch to incorporate main's latest
changes — this keeps history linear and avoids merge commits cluttering your branch. Use git
merge feature on main to integrate completed features — this preserves the record of the
feature's existence. Implication: This is the most pragmatic merge/rebase strategy and works
for most teams. Rebase for "keeping up," merge for "finishing up." The exception: never rebase
shared branches (see above). Rating: 5
Rating 4 — These Change How You Work Daily
Use --no-ff When Merging Feature Branches to Main
Source: Git Project Management (Ch3.6, Ch8.3), Git for Teams (Ch4) Statement: git merge
--no-ff feature forces a merge commit even when a fast-forward is possible. This
preserves a visible "bump" in the commit graph showing that a feature branch existed and was
integrated. Implication: Without --no-ff, fast-forward merges make it impossible to tell that a
branch ever existed. For feature branches, the merge commit serves as documentation: "here's
where feature X was integrated." For trivial changes, fast-forward is fine. Rating: 4
Resolve Conflicts One at a Time Using git status as a TODO List
Source: Advanced Git 2nd Ed (Ch2), Git Project Management (Ch3.9) Statement: During a
merge conflict, git status lists every file with conflicts under "Unmerged paths." Fix one file,
git add it, then check status again. The list shrinks. When empty, run git commit to
complete the merge. Implication: Don't try to fix all conflicts at once. Treat each conflicted file
as a task. Add it after fixing to mark it done. This systematic approach prevents missing conflicts
and reduces panic. Rating: 4
Enable diff3 Conflict Style for Three-Way View
Source: Advanced Git 2nd Ed (Ch2), Git Project Management (Ch3.9) Statement: git
config [Link] diff3 adds a third section to conflict markers showing the
common ancestor — what the code looked like before either branch changed it. This makes
conflicts dramatically easier to resolve because you can see the intent of each change.
Implication: The default two-way conflict view (ours vs theirs) forces you to guess what the
original code was. Three-way view eliminates that guessing. Set this globally and never go
back: git config --global [Link] diff3. Rating: 4
Interactive Rebase Is for Cleaning, Not Changing
Source: Advanced Git 2nd Ed (Ch5), Git Project Management (Ch3.10) Statement: git
rebase -i lets you squash, reorder, reword, and drop commits on unpushed branches. Use it
to turn messy development commits into clean, logical commits before pushing. Commands:
pick (keep), squash (combine with previous), reword (change message), drop (remove),
edit (stop for amending). Implication: Work messily, commit often for safety, then clean up
with interactive rebase before pushing. This gives you the safety of frequent commits AND the
clarity of intentional history. But only on unpushed branches. Rating: 4
git merge --abort Is Your Emergency Exit
Source: Git Project Management (Ch3.9), Advanced Git 2nd Ed (Ch2) Statement: If you start a
merge and the conflicts are too complex to resolve right now, git merge --abort returns
everything to the state before you started the merge. Similarly, git rebase --abort exits a
rebase in progress. Implication: You are never trapped in a merge or rebase. If things go
sideways, abort and regroup. This knowledge alone reduces the panic that causes destructive
mistakes. Rating: 4
Rating 3 — These Sharpen Judgment
Delete Feature Branches After Merging
Source: Multiple books; Git for Teams (Ch5), Advanced Git 2nd Ed (Ch9) Statement: After
merging a feature branch to main, delete it locally with git branch -d feature and
remotely with git push origin --delete feature. The commits are preserved in main's
history. Implication: Stale branches accumulate and confuse. If the merge used --no-ff, the
branch's existence is recorded in the merge commit. The branch name itself is just a pointer —
deleting it doesn't delete the commits. Rating: 3
git branch -d vs -D: Safe Delete vs Force Delete
Source: Advanced Git 2nd Ed (Ch2), Git Project Management (Ch3.5) Statement: -d
(lowercase) only deletes a branch if its commits have been merged elsewhere. -D (uppercase)
deletes regardless, potentially losing unmerged work. Git uses this distinction to protect you.
Implication: Always try -d first. If Git refuses, it's telling you that branch has unmerged
commits. Decide deliberately whether to force-delete with -D or merge first. Rating: 3
Cherry-Pick for Surgical Commit Transfer
Source: Git Project Management (Ch3.6), Advanced Git 2nd Ed (Ch4) Statement: git
cherry-pick <hash> applies the changes from a single commit to the current branch without
merging the entire source branch. Use it when you need one specific fix from another branch
but not everything else. Implication: Cherry-pick is not a substitute for proper branching and
merging. It creates duplicate commits (different hashes, same changes) which can cause
confusion during future merges. Use sparingly and for clear reasons like applying a hotfix from
main to a release branch. Rating: 3
Squash Merges Lose Branch History
Source: Git Project Management (Ch3.10), Advanced Git 2nd Ed (Ch9) Statement: git
merge --squash feature combines all commits from the feature branch into a single new
commit on the target branch. Unlike a regular merge, the squashed commit has no parent
reference to the feature branch. Implication: Squash merging produces the cleanest possible
history but makes it impossible to trace back to the individual commits that built the feature. Use
it for small features where the individual commits aren't informative. Avoid for large features
where the commit-by-commit story matters. Rating: 3
Octopus Merges Exist But Don't Use Them
Source: Git Project Management (Ch3.6) Statement: git merge branch1 branch2
branch3 merges multiple branches simultaneously in an "octopus merge." This is technically
possible and used in the Linux kernel but is extremely difficult to resolve if conflicts occur.
Implication: Unless you're Linus Torvalds, stick to merging one branch at a time. Sequential
merges are easier to understand, debug, and resolve. Rating: 2
Rating 2 — These Refine Practice
git switch Is the Modern Alternative to git checkout for Branches
Source: Git Project Management (Ch3.5), Git Apprentice (Ch7) Statement: Since Git 2.23
(2019), git switch <branch> replaces git checkout <branch> for switching branches,
and git restore replaces git checkout -- <file> for restoring files. The new
commands are less overloaded and less confusing. Implication: git checkout does too
many things (switch branches, restore files, create branches, detach HEAD). The new
commands are clearer. But git checkout still works and is more universally known, so both
are valid. Rating: 2
Branch Names Should Include Ticket Numbers
Source: Git for Teams (Ch4), Git Project Management (Ch8) Statement: Name branches with
the ticket/issue number and a terse description: 1234-fix-login-timeout, feature/add-
search. This creates traceability from branch to requirement. Implication: Consistent naming
makes it easy to find branches, understand their purpose, and automate ticket-status updates.
Establish a team convention and enforce it. Rating: 2