Table of contents
Understand what each strategy changes
`merge` keeps existing commits and adds a merge commit that records convergence. `rebase` rewrites commit ancestry and produces new commit IDs.
If your team values exact chronology of collaboration, merge commits are often preferred. If your team wants linear history for easier bisect and release notes, rebasing feature branches can be appropriate.
Use a risk model before choosing
For protected branches, prefer normal merges through pull requests. For local feature cleanup before opening review, interactive rebase can reduce noise.
Never rewrite history that others have already pulled unless everyone agrees on the recovery plan.
Adopt one team policy and enforce it
Codify when to squash, when to merge, and when rebasing is allowed. Document expectations for conflict handling and verification after integration.
Automation should enforce branch protection, required checks, and non-fast-forward rules aligned with that policy.
Command checklist
git fetch origingit rebase origin/maingit merge origin/maingit rebase --abortgit push --force-with-lease
Review checklist
- Confirm whether branch history is shared.
- Choose merge for audit clarity on shared branches.
- Use rebase for local cleanup before review.
- Resolve conflicts deliberately and retest.
- Use force-with-lease only when policy permits.