June 30, 2025 9 min to read

Understanding Git Merge vs Rebase

A comprehensive guide to branch integration strategies in Git

Overview

Git’s Merge and Rebase commands both integrate changes between branches but differ significantly in how they manage project history.

Merge combines the work of multiple branches into a single merge commit, preserving a non-linear history that clearly shows the workflow of different branches.

Rebase replays the commits from one branch onto another branch’s latest commit, maintaining a linear history that can be easier to follow.

Additionally, understanding the concepts of “ours” and “theirs” during conflict resolution is crucial, as their meanings change depending on whether you’re performing a merge or rebase operation.

This guide provides practical examples of these concepts, interactive rebase commands, and strategies for choosing the appropriate method for different situations. It will help you maintain a clean history during collaboration and effectively resolve branch conflicts.

Git Rebase

Rebase is a powerful Git feature used to integrate changes from one branch to another by moving or “replaying” commits from a feature branch onto another branch (typically the main branch). The primary goal of rebase is to create a linear project history.

Functions in Rebase

Several common functions are available during an interactive rebase (git rebase -i):

• pick: Use the commit as is without modification
• reword: Use the commit but change the commit message
• edit: Pause the rebase at this commit to allow any kind of changes (code changes, splitting the commit, further amends)
• squash: Combine this commit with the previous one and prompt for a new commit message
• fixup: Similar to squash, but keep the previous commit’s message and discard this commit’s log message
• drop: Remove the commit completely from history

Git Merge

Merge is used to integrate changes from one branch into another by creating a new “merge commit” that combines the changes from the merged branch. This creates a non-linear history.

Understanding “ours” and “theirs” in Git

When resolving conflicts in Git, especially during merge and rebase operations, “ours” and “theirs” provide ways to reference changes from different points.

In Merge

• ours: Refers to the current branch, which is the target branch where another branch is being merged. If you’re merging a feature branch into main and you’re on the main branch, “ours” represents the changes in the main branch.
• theirs: Refers to the branch being merged into the target branch. Continuing the example above, “theirs” represents the changes in the feature branch.

In Rebase

• ours: Changes depending on the context. During a rebase, “ours” represents the changes in the branch being rebased onto another branch. If you’re rebasing a feature branch onto main, when conflicts occur, “ours” refers to what was originally in the feature branch.
• theirs: In the context of rebase, “theirs” represents the branch that provides the new base for the branch being rebased. If you’re rebasing a feature branch onto main, “theirs” represents the changes in the main branch at the point where the rebase is being applied.

Practical Usage

Merge Scenario

When merging two branches and conflicts occur, you can choose between “ours” or “theirs” resolution methods depending on your perspective (target or incoming branch) and which changes you want to prioritize.

# Accept our version during merge conflict
git merge -X ours feature-branch

# Accept their version during merge conflict
git merge -X theirs feature-branch

# During conflict resolution, choose specific files
git checkout --ours path/to/file.txt
git checkout --theirs path/to/file.txt

Rebase Scenario

Choosing between “ours” and “theirs” during a rebase can be more confusing because the roles switch depending on the changes and base context. Remember that “ours” is the branch being rebased (current) and “theirs” is the branch being rebased onto (conflicting).

# During rebase conflict resolution
git checkout --ours path/to/file.txt   # Keep the feature branch version
git checkout --theirs path/to/file.txt # Keep the main branch version

# After resolving conflicts
git add path/to/file.txt
git rebase --continue

Popular Commands in Merge vs. Rebase

Merge is often used with options like --no-ff (no fast-forward) to create a merge commit even in cases where a fast-forward merge would be possible, preserving information about the past existence of a feature branch.

# Create a merge commit even if fast-forward is possible
git merge --no-ff feature-branch

# Merge with a custom commit message
git merge --no-ff -m "Merge feature X into main" feature-branch

Rebase is frequently used with --interactive to clean up a series of changes before merging them into the main project branch.

# Interactive rebase for the last 3 commits
git rebase -i HEAD~3

# Rebase feature branch onto main
git checkout feature-branch
git rebase main

# Interactive rebase onto main
git rebase -i main

Conclusion

Git’s Rebase and Merge are vital branch integration tools, each with its own purpose and advantages.

Merge safely preserves changes between branches and maintains a record, while Rebase is effective for maintaining a clean, linear commit history.

However, these two methods can cause confusion because “ours” and “theirs” are interpreted differently during conflict resolution. It’s crucial to choose and use these commands carefully based on a thorough understanding.

In team collaboration, discussing how to manage commit history and which strategy is better is essential. Flexibility in choosing between Rebase and Merge based on the situation is necessary.

Ultimately, consistency in history and efficiency in collaboration are what matter. Keeping things well-organized helps greatly with tracking history and debugging later.

References

• Git Documentation - Rebasing
• Understanding Git Rebase
• The Definitive Guide to Ours and Theirs in Git
• Deep Dive into Git Rebase