Skip to main content

Branches, Merge, and Rebase

What This Concept Is​

Branches let you isolate work. Merging combines lines of development. Rebasing replays one branch's commits onto a new base. All three operations make sense only if you remember that branches are references to commits, not folders.

In everyday Git:

  • use topic branches to isolate one task
  • use merge to combine shared history safely
  • use rebase to clean up local unpublished history

Why It Matters Here​

Branching is where Git becomes genuinely powerful. Cheap branches let you work in small, reviewable units. But branching without a model creates confusion: people think rebase "changes code mysteriously" or that a merge commit means failure.

You need a simple rule:

  • local cleanup can be rebased
  • shared history should usually be merged, not rewritten

Concrete Example​

Typical feature flow:

git switch -c feature/login
# make commits
git switch main
git merge feature/login
git branch -d feature/login

Separate example in a fresh repository where feature/login still exists and has not been integrated: local cleanup before sharing. The preceding example deleted that branch, so these are not consecutive command blocks.

git switch feature/login
git fetch origin
git rebase origin/main

If the rebase succeeds, your feature branch now appears as if it started from the newer origin/main, but you have rewritten commit history on your local branch. That is why this is safe only before others depend on it.

Common Confusion / Misconception​

Misconception: Rebasing and merging are interchangeable in every situation.

Correction: They can produce the same final file content, but they produce different histories. Rebase rewrites commits. Merge preserves both lines of history and adds an integration point when needed.

Misconception: A merge commit means you did something wrong.

Correction: Merge commits are normal records of integration. The problem is not "having a merge commit." The problem is integrating carelessly.

How To Use It​

Use this decision rule:

  • use a topic branch for every coherent task
  • merge when bringing shared work together
  • rebase only when the branch is still local or coordination is explicit

One sentence rule worth memorizing:

  • rebase your own work, merge shared work

Check Yourself​

  1. Why is creating a branch cheap in Git?
  2. What is the main risk of rebasing a branch other people already use?
  3. When is a merge commit the right result?

Mini Drill or Application​

In a throwaway repository:

  1. create feature-a from main
  2. make two commits on feature-a
  3. make one commit on main
  4. rebase feature-a onto main
  5. inspect the graph
  6. repeat the scenario, but merge instead of rebase
  7. explain the difference in history, not just in final files

Read This Only If Stuck​