| English | 中文 |
Both merge and rebase can combine two histories together, but they express different collaborative semantics.
Simply put:
merge preserves the branch merge historyrebase moves the commits of the current branch onto a new baseWhen the history on a public branch has already been seen or built upon by others, prioritize using merge or revert to avoid casually rewriting history.
If a feature branch represents a complete set of work, a merge commit can preserve the context of this integration.
Some teams want to see from the history “when which branch was merged in”; in this case, merge is more appropriate.
When local commits have not yet been pushed, you can use interactive rebase to clean up commits:
git rebase -i HEAD~3
Common operations:
git fetch origin
git rebase origin/main
This allows your branch history to be placed right after the latest main branch.
Some teams prefer a linear history and will require feature branches to be rebased onto the latest position of the main branch before merging.
Avoid rebasing public branches that have already been built upon by others.
GitHub documentation also warns that rebase rewrites commit history. Rebasing commits that have already been pushed to the repository will cause trouble for other collaborators.
| Scenario | Recommendation |
|---|---|
| Cleanup of unpushed local commits | rebase |
| Syncing feature branch with main branch | rebase or merge, depending on team convention |
| Merging PRs into the main branch | merge, squash, or rebase merge, depending on repository strategy |
| Fixing errors in public history | revert |
| Someone has already built upon your branch | Avoid rebase |
git merge feature/login
git rebase origin/main
git rebase -i HEAD~3
git rebase --abort
git rebase --continue