History shape after integration
A merge commit records the exact moment two lines of development came together. The resulting graph shows branches diverging and then joining, which makes it simple to trace when a feature was incorporated and who performed the integration.
Rebasing eliminates the merge commit by creating new commits that sit directly on the tip of the target branch. The history becomes a single straight line, which simplifies commands such as git log and git bisect because there are no forks to navigate.
- Merge keeps the complete record of when branches diverged and converged.
- Rebase produces a linear sequence that is easier to read but loses the explicit integration event.
Collaboration risk and the golden rule
The primary danger with rebasing is that it rewrites commit hashes. Once a branch is pushed and other developers have based their work on those commits, a rebase forces them to reconcile their local history with the rewritten version. This can lead to duplicate commits or lost changes if teammates are not prepared.
Merge is a non-destructive operation. Existing commits remain unchanged, so anyone who has already fetched the branch sees the same history before and after the merge. For this reason, shared or public branches should always use merge.
- Ask whether anyone else is looking at the branch before running rebase.
- If the answer is yes, choose merge or revert instead of rewriting history.
How conflicts are presented and resolved
Both commands stop when they encounter a conflict that cannot be resolved automatically. With merge, the working tree and index reflect the state after the attempted merge, and you edit files, stage them, then run git merge --continue. With rebase, the process stops at the first conflicting commit; you fix the conflict, stage the result, and run git rebase --continue to replay the remaining commits.
Rebase can surface the same conflict multiple times if the same lines are touched in several commits being replayed. Merge records the conflict once in a single merge commit. After resolution, the final state of the files is identical in both cases.
- Edit conflicted files, stage with git add, then continue with the appropriate command.
- Use git merge --abort or git rebase --abort to discard the attempt and return to the starting state.
Team conventions and pull request workflows
Many teams adopt a convention that private feature branches may be rebased to stay current with main, while the final integration into main always uses a merge commit. This keeps the main branch history readable yet still records when each feature landed. Interactive rebase can also be used on a private branch to squash or reorder commits before opening a pull request.
When compliance or audit requirements demand an explicit record of every integration, teams prefer merge. When the priority is a clean, linear history that is easy to follow with git log, rebase on private branches is acceptable provided the golden rule is observed.
- Rebase a local feature branch before opening a pull request to avoid unnecessary merge commits.
- Use merge when multiple developers collaborate on the same branch or when an audit trail is required.
Practical decision guide
Start with the question of whether the branch is private. If it has never been pushed or is used only by you, rebase is safe and produces a cleaner result. If the branch is shared or already pushed, merge is the safer default. When preparing a pull request, a final rebase onto the latest main keeps the review focused on the feature changes rather than on merge noise.
Both operations are reversible with enough care. Merge commits can be reverted; rebased commits can be recovered from the reflog for a limited time. The key is to agree on the convention within the team and apply it consistently so that every developer knows what to expect when they fetch or review a branch.
- Private branch, want linear history: rebase.
- Shared branch or audit needs: merge.
- Before a pull request on a private branch: rebase, then merge.