A Brief Discussion on the Differences Between Git Merge and Rebase

TLDR

• git merge preserves the complete history and merge points, making it suitable for merging heterogeneous branches (e.g., main and develop).
• git rebase rewrites history to maintain a linear progression, making it suitable for synchronizing homogeneous branches (e.g., origin/main and main).
• git merge requires resolving conflicts at most once; with git rebase, if multiple commits encounter conflicts, you may need to resolve them multiple times.
• It is strictly forbidden to perform git rebase on shared branches that have already been pushed to a remote, as this can cause a disaster for team collaboration.
• Using git pull --rebase can avoid unnecessary merge commits when synchronizing remote changes.

Two Ways to Merge Branches

In Git, there are two main ways to merge branches: git merge and git rebase. Both have very different effects on the Commit History.

git merge

When to use: When you need to integrate two branches with different development goals (heterogeneous branches).

• Pros:
  • Preserves the complete history, including the timestamps of each merge.
  • When merging between heterogeneous branches, it is clear how changes were integrated.
  • You only need to check for conflicts against the latest commit of the target branch, requiring at most one conflict resolution.
• Cons:
  • Frequent merging can make the history complex.
  • Generates a large number of merge commits, leading to a cluttered history.

git rebase

When to use: When you need to organize the branch history to make it look clean and linear.

• Pros:
  • Organizes the commit history, making it look cleaner and linear.
• Cons:
  • Rewriting history results in the loss of original merge points.
  • In a multi-person collaborative environment, rewriting history causes confusion.
  • During the rebase process, each commit is checked for conflicts, which may require multiple conflict resolutions.

Branch Graph Examples

The following uses Mermaid to visualize the differences between the two:

Original Branch History:

Result of Merge:

Result of Rebase:

Usage Timing and Recommendations

Determining Branch Homogeneity

• Homogeneous branches: Refers to different versions of the same branch on remote and local (e.g., origin/main and main). Using git rebase is recommended.
• Heterogeneous branches: Refers to branches with different goals (e.g., main and develop). Using git merge is recommended.

Practical Recommendations

• git pull is essentially git fetch followed by git merge. If you wish to maintain a linear history, it is recommended to use git pull --rebase to integrate local changes on top of remote changes.
• Before sending an MR (Merge Request), it is recommended to use git rebase to move the current branch to the latest state of the target branch, ensuring there are no conflicts before submitting.

TIP

The responsibility for resolving conflicts—whether it lies with the reviewer or the MR submitter—varies by team; please follow your team's specific guidelines.

WARNING

Except for git pull --rebase, Rebase-related operations should only be performed on your own development branches; do not perform them on shared branches.

Rebase operations on shared branches should only be performed before a git push has been executed. Once git push has occurred, changing the local repository's commit history will cause the local and remote histories to diverge. If you use git push --force to forcibly update the remote repository, it will cause inconsistencies with the local repositories of other team members. Such operations not only affect team collaboration but may also trigger disputes.

Change Log

• 2024-08-23 Initial document creation.