← Back to Articles         
Git Rebase and Merge vs Rebase

Git Rebase and Merge vs Rebase

Published on 03 Oct 2026     5 min read Git & GitHub
Merge vs Rebase

Git Rebase and Merge vs Rebase

1. What is Git rebase, and why is it used?

What is Git Rebase?

Git rebase is used to move or reapply the commits of one branch on top of another branch.

In simple terms:

Rebase updates your branch with the latest changes from another branch while keeping the commit history linear and cleaner.

Suppose you create feature/login from main.

Initially:

A --- B
      \
       C --- D

Then other developers add commits to main:

A --- B --- E --- F    main
      \
       C --- D         feature/login

Your feature branch is now based on an older version of main.

You can rebase it onto the latest main:

git switch feature/login
git rebase main

Git takes your feature commits C and D and reapplies them after F:

A --- B --- E --- F --- C' --- D'
                  main          feature/login

Notice that Git creates:

C' and D'

instead of using the original C and D.

This happens because rebase rewrites the commit history, creating new commits with new commit hashes.


Why is Rebase Used?

The main reason is to maintain a clean, linear commit history.

Without rebase, development history may look like:

A --- B --- E --- F
      \           \
       C --- D ---- M

With rebase:

A --- B --- E --- F --- C' --- D'

The second history is easier to read because the commits appear sequentially.


Simple Rebase Example

Assume:

main
feature/login

First update main:

git switch main
git pull

Switch to your feature branch:

git switch feature/login

Rebase it:

git rebase main

Complete syntax:

git switch main
git pull

git switch feature/login
git rebase main

Now feature/login is based on the latest main.


What Happens Internally?

Suppose:

A --- B --- E --- F    main
      \
       C --- D         feature/login

When you execute:

git rebase main

Git roughly performs these steps:

  1. Finds the common ancestor (B).
  2. Identifies feature commits C and D.
  3. Temporarily sets them aside.
  4. Moves the feature branch to F.
  5. Reapplies the changes from C.
  6. Reapplies the changes from D.

Result:

A --- B --- E --- F --- C' --- D'

Because C' and D' have different parents from the original commits, they have new commit hashes.


What if There is a Conflict?

If Git finds a conflict during rebase, it pauses.

Check:

git status

Fix the conflicting files and stage them:

git add .

Then continue:

git rebase --continue

If you want to cancel the rebase:

git rebase --abort

So a typical conflict flow is:

git rebase main

# Fix conflicts

git add .
git rebase --continue

Key Points

  • git rebase reapplies commits on top of another base.
  • It is commonly used to update a feature branch with the latest main.
  • It produces a cleaner, linear history.
  • Rebase rewrites commit history.
  • Rebasing creates new commit hashes for the reapplied commits.
  • Be careful when rebasing commits that have already been shared with other developers.
  • Useful commands:
git rebase main
git rebase --continue
git rebase --abort

2. What is the difference between merge and rebase?

Both merge and rebase can be used to bring changes from one branch into another, but they handle the Git history differently.

Suppose:

A --- B --- E --- F    main
      \
       C --- D         feature/login

Using Merge

Switch to the feature branch:

git switch feature/login
git merge main

The histories are combined.

Conceptually:

A --- B --- E --- F
      \           \
       C --- D ---- M
                    feature/login

M is a merge commit when Git requires one.

The original commits remain unchanged:

C
D

Therefore, merge generally preserves the existing history.


Using Rebase

Instead:

git switch feature/login
git rebase main

Result:

A --- B --- E --- F --- C' --- D'
                  main          feature/login

The original feature commits are recreated:

C → C'
D → D'

Therefore, rebase rewrites that part of the history.


Merge vs Rebase

Merge Rebase
Combines two histories Reapplies commits on another base
Preserves existing commits Rewrites rebased commits
May create a merge commit Usually avoids an extra merge commit
History can become more branched Produces linear history
Safer for shared branch history Requires care with shared history
git merge main git rebase main

Simple Visual Comparison

Before:

A --- B --- E --- F    main
      \
       C --- D         feature

After Merge:

A --- B --- E --- F
      \           \
       C --- D ---- M

After Rebase:

A --- B --- E --- F --- C' --- D'

When Should You Use Each?

Merge

Merge is commonly appropriate when you want to preserve the actual branch history, especially when working with shared branches.

git merge main

Rebase

Rebase is useful when you want to update your feature work while maintaining a clean, linear history.

git rebase main

However, avoid casually rebasing commits that other developers have already based their work on.

Key Points

  • Both merge and rebase integrate changes.
  • Merge preserves history.
  • Rebase rewrites history.
  • Merge may introduce a merge commit.
  • Rebase can make history more linear.
  • Rebase is often useful for local/private feature branch cleanup.
  • For shared branches, follow your team's branching policy.

Interview Answer

Merge combines the histories of two branches and preserves the existing commits, often creating a merge commit. Rebase moves my branch onto a new base by replaying its commits, which creates a cleaner linear history but rewrites commit history. I use the approach defined by the team's Git workflow.

← Back to Articles