Merge vs Rebase - Case Study

2 min

Table of contents

  1. The Problem
  2. Solution 1: Merge
  3. Solution 2: Rebase
  4. Practical Comparison
  5. Which Approach to Choose?

1. The Problem

Typical situation:

  • You are developing on feature-branch
  • Meanwhile, main moves forward (colleagues push)
  • You want to integrate your work into main

2 possible strategies:

  1. MERGE: Merge the branches
  2. REBASE: Rewrite the history

Back to table of contents

2. Solution 1: Merge

Scenario setup:

bash
mkdir demo-merge && cd demo-merge && git init

# Common base
echo "print('app v1')" > app.py
git add . && git commit -m "Initial version"

# Feature branch
git checkout -b feature-login
echo "print('login system')" > login.py
git add . && git commit -m "Add login"
echo "print('login v2')" > login.py
git add . && git commit -m "Improve login"

# Main moves forward in the meantime
git checkout main
echo "print('app v1.1')" > app.py
git add . && git commit -m "Update main app"

Merge:

bash
git merge feature-login

Merge result:

*   Merge branch 'feature-login'
|\
| * Improve login
| * Add login
* | Update main app
|/
* Version initiale

History: Clearly shows that there were 2 parallel lines of development.

Back to table of contents

3. Solution 2: Rebase

Identical setup, different strategy:

bash
mkdir demo-rebase && cd demo-rebase && git init

# Same setup as before...
echo "print('app v1')" > app.py
git add . && git commit -m "Initial version"

git checkout -b feature-login
echo "print('login system')" > login.py
git add . && git commit -m "Add login"
echo "print('login v2')" > login.py
git add . && git commit -m "Improve login"

git checkout main
echo "print('app v1.1')" > app.py
git add . && git commit -m "Update main app"

Rebase:

bash
git checkout feature-login
git rebase main              # "Moves" your commits after main
git checkout main
git merge feature-login      # Fast-forward merge

Rebase result:

* Improve login
* Add login
* Update main app
* Version initiale

History: Linear, as if you had developed after the main updates.

Back to table of contents

4. Practical Comparison

AspectMERGEREBASE
HistoryShows parallel branchesLinear, clean
Merge commitYes, created automaticallyNo, fast-forward
ComplexitySimpleMore complex
ConflictsResolve oncePossibly several times
TraceabilitySee when the feature was created/mergedAs if developed sequentially

Side-by-side visualization:

MERGE:

    A---B---C main
   /         \
  D---E---F---G feature (merge commit G)

REBASE:

A---B---C---D'---E'---F' main (commits D,E,F "moved")

Back to table of contents

5. Which Approach to Choose?

Use MERGE when:

  • You are starting with Git
  • You want to keep the "true" history
  • The team works on long-lived branches
  • Safety first

Command:

bash
git checkout main
git merge feature-branch

Use REBASE when:

  • You want a clean, linear history
  • Short and personal feature branch
  • The team prefers a "story-like" history
  • You have a good command of Git

Command:

bash
git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch    # Fast-forward

GOLDEN RULE:

NEVER rebase commits that are already shared/pushed!

Simple recommendation:

  • Beginner → Always MERGE
  • Experienced → REBASE on personal branches, MERGE to share

Both work. The important thing = consistency in the team!

Back to table of contents

Git Workflow - First ExerciseGit Squash