git rebase vs git merge: When to Rebase, and the Golden Rule of Rebasing

This course has touched on the rebase-versus-merge trade-off repeatedly — in Module 4's pull --rebase lesson, Module 5's PR merge strategies lesson, and the previous two lessons in this module. This lesson consolidates all of that into one clear decision framework, and states explicitly the single most important safety rule governing when rebasing is appropriate at all.

Learning Objectives

Consolidate the practical trade-offs between rebase and merge covered throughout this course.
State and explain the golden rule of rebasing.
Understand exactly why violating the golden rule causes real problems for collaborators.
Apply the golden rule to decide when rebase is and isn't an appropriate choice.

Key Terms to Know Before Comparing git rebase and git merge

Golden rule of rebasing: Never rebase commits that have already been pushed to a shared remote and might have been pulled by someone else.
Local-only commits: Commits that exist solely on your own machine and have not yet been shared with any collaborator, safe to rebase freely.
Diverged history: The state that results when a rebased commit's new hash no longer matches what a collaborator already has for what was conceptually 'the same' commit.
Force push: Pushing a rewritten history (such as after a rebase) that overwrites a remote branch's existing commits, required whenever pushing rebased, already-pushed commits.

How to Decide Between git rebase and git merge

By this point in the course, you've encountered the rebase-versus-merge decision in several different contexts: choosing between `git merge` and `git rebase` when integrating a fork's upstream changes (Module 5), choosing a PR merge strategy on GitHub (Module 5), and now the general-purpose `git rebase` and interactive rebase covered in this module. It's worth consolidating the practical guidance:

**Prefer rebase when:**
- You want a clean, linear history without routine 'sync' merge commits.
- You're cleaning up your own **local, not-yet-pushed** commits before sharing them (interactive rebase, previous lesson).
- You're keeping a feature branch current with an upstream/main branch that has advanced, before opening a pull request.

**Prefer merge when:**
- You want to preserve the complete, accurate historical record of when and how two branches actually diverged and reunited, including an explicit merge commit.
- You're integrating a branch that has already been shared or reviewed by others, where its existing commit hashes matter to someone else's history.
- Your team's convention (Module 5's merge strategy lesson) simply prefers merge commits for traceability.

But underlying all of this nuance is a single, non-negotiable safety principle, often called the **golden rule of rebasing**:

> **Never rebase commits that have already been pushed to a shared remote and might have been pulled by someone else.**

This directly echoes and generalizes the caution from Module 2's `git commit --amend` lesson, since rebasing has the exact same fundamental risk: it replaces existing commits with new ones bearing different hashes. If you rebase commits that a collaborator has already pulled, you and they now have two different, diverged versions of what should be 'the same' history — your rebased commits have new hashes that don't match what they already have locally. When you then try to push your rebased branch, Git will reject it as a non-fast-forward push (since your history has diverged from the remote), and the only way to push anyway requires a **force push** (`git push --force` or the safer `--force-with-lease`), which overwrites the remote's existing commits — potentially silently erasing any work a collaborator built on top of the original, pre-rebase commits, since those original commits effectively cease to exist on the remote once overwritten.

The safe, practical litmus test: **rebase freely on commits that exist only on your own machine.** Once you've pushed a branch and there's a real possibility someone else has pulled it, rebasing that branch's history becomes risky and should generally be avoided, or at minimum requires explicit coordination with everyone who might have already pulled it, warning them a force push is coming and they'll need to specifically reconcile their own local copy afterward.

The Golden Rule of Rebasing: Visual Walkthrough

Draw two scenarios. LEFT (safe): 'Local commits, never pushed' → arrow labeled 'git rebase' → 'New commits with new hashes — SAFE, no one else has the originals.' RIGHT (unsafe): 'Commits already pushed AND pulled by a collaborator' → arrow labeled 'git rebase' → 'New commits with new hashes' → warning icon → 'Collaborator still has the OLD commits — pushing now requires --force, risking their work being silently overwritten.' Caption beneath both: 'Golden rule: only rebase commits that exist SOLELY on your own machine.'

When to Rebase vs When to Merge: Quick Reference Table

Situation	Rebase Safe?	Reasoning
Local commits, never pushed anywhere	Yes	No one else has these commits; replacing them affects only your own local history
Pushed, but confirmed no one has pulled yet	Risky	Technically may be safe, but hard to be fully certain no one has fetched it
Pushed and confirmed pulled by a collaborator	No	Rebasing creates diverged history; force-pushing can overwrite their subsequent work
Your own feature branch, before opening a PR	Yes (typical case)	Usually still local-only or not yet built upon by others at this stage

Golden Rule in Practice: Safe vs Unsafe Examples

# SAFE: rebasing commits that exist only locally
git switch feature/dark-mode   # never pushed yet
git rebase main
git push -u origin feature/dark-mode   # first push, no force needed

# RISKY / VIOLATES THE GOLDEN RULE: rebasing already-pushed, shared commits
git switch feature/dark-mode   # already pushed AND pulled by a collaborator
git rebase main
git push
# ! [rejected] feature/dark-mode -> feature/dark-mode (non-fast-forward)
# error: failed to push some refs...

# Forcing it through overwrites the remote's history:
git push --force-with-lease
# (safer than --force, but STILL risks overwriting a collaborator's subsequent work
#  if they had already built on the original, pre-rebase commits)

Breaking Down the Golden Rule Example

The first block shows the safe case: rebasing a branch that has never been pushed means the resulting new commit hashes have no conflicting history anywhere else, so the first push proceeds normally with no force required. The second block shows the risky case: rebasing an already-shared branch produces new hashes that no longer match what's on the remote (and what a collaborator may have already pulled), causing a rejected, non-fast-forward push. The final `--force-with-lease` command demonstrates the only way to push through this situation — a safer variant of `--force` that checks the remote hasn't changed unexpectedly since you last fetched, but which still fundamentally overwrites history and can cause real problems if a collaborator has already built work on top of the original commits.

How Teams Apply the Golden Rule of Rebasing in Practice

Nearly every team's Git conventions document explicitly states some version of the golden rule, since violating it is one of the most common sources of confusing, disruptive Git incidents on collaborative projects.
Many organizations configure branch protection rules (Module 4) that specifically disable force-pushing to shared branches like main, technically enforcing the golden rule rather than relying purely on developer discipline.
Developers cleaning up their own feature branch with interactive rebase before opening a pull request are operating squarely within the golden rule's safe zone, since the branch typically hasn't been shared with anyone else yet.
In rare, carefully coordinated situations (like a team lead cleaning up a shared branch's history with everyone's explicit knowledge and agreement), teams do sometimes deliberately violate the golden rule, but always with direct communication to every affected collaborator beforehand.

git rebase vs git merge Interview Questions and Answers

Q1. What is the golden rule of rebasing?

Never rebase commits that have already been pushed to a shared remote and might have been pulled by someone else. Since rebasing replaces commits with new ones bearing different hashes, doing this on shared commits creates diverged history between you and anyone who already has the originals.

Q2. What happens if you violate the golden rule and then try to push your rebased branch?

The push is rejected as a non-fast-forward, since your local history has diverged from the remote's. Pushing through requires a force push, which overwrites the remote's existing commits and can silently erase any work a collaborator built on top of the original, pre-rebase commits.

Q3. In general terms, when would you prefer rebase over merge, and vice versa?

Prefer rebase for a clean, linear history when cleaning up your own local, not-yet-shared commits, or keeping a feature branch current before opening a pull request. Prefer merge when you want to preserve the complete, accurate record of how branches diverged and reunited, or when integrating a branch that's already been shared or reviewed by others.

Golden Rule of Rebasing Quiz: Test Your Understanding

1. What is the golden rule of rebasing?

Always rebase before merging any branch
Never rebase commits that have already been pushed and might have been pulled by someone else
Rebase should never be used under any circumstances
Only rebase branches longer than 10 commits

Answer: B. Never rebase commits that have already been pushed and might have been pulled by someone else

Explanation: This is the core safety principle governing rebase usage — rebasing shared, already-pulled commits creates diverged history that can disrupt collaborators.

2. What happens when you try to push a branch after rebasing commits that were already pushed and pulled by a collaborator?

The push succeeds normally with no issues
The push is rejected as non-fast-forward, requiring a force push to override
Git automatically merges the two histories
The rebase is automatically undone

Answer: B. The push is rejected as non-fast-forward, requiring a force push to override

Explanation: Since the rebased commits have new hashes diverging from what's on the remote, a normal push is rejected; only a force push (which overwrites remote history) can push it through.

3. Why is rebasing your own local, never-pushed commits considered safe?

Local commits cannot technically be rebased
No one else has those commits, so replacing them with new hashes doesn't create diverged history for anyone
Local rebasing doesn't actually change any commit hashes
It's not actually safe under any circumstances

Answer: B. No one else has those commits, so replacing them with new hashes doesn't create diverged history for anyone

Explanation: Since local-only commits haven't been shared with anyone, rebasing and replacing their hashes has no effect on anyone else's history, making it a safe, common operation.

Common Mistakes Violating the Golden Rule of Rebasing

Rebasing a branch that a collaborator has already pulled, without warning them, resulting in a confusing, disruptive diverged history for the whole team.
Force-pushing carelessly without using the safer --force-with-lease variant, increasing the risk of silently overwriting a collaborator's unseen work.
Applying the golden rule too rigidly and avoiding rebase entirely, even in genuinely safe, local-only situations where it would provide real benefit.
Not recognizing that a plain git commit --amend (Module 2) carries the exact same underlying risk as rebase, since both replace existing commits with new hashes.

git rebase vs git merge: Exam-Ready Quick Notes

Golden rule: never rebase commits already pushed and possibly pulled by someone else.
Violating it: rebased commits get new hashes, causing a non-fast-forward push rejection.
Force push (--force or safer --force-with-lease) is required to push through, overwriting remote history.
Safe zone: local-only, never-pushed commits — rebase freely here.

git rebase vs git merge: Key Takeaways

The golden rule of rebasing — never rebase already-shared commits — is the single most important safety principle governing this entire module's tools.
Rebase and commit --amend (Module 2) share the exact same underlying risk, since both replace existing commits with new hashes.
The safe, practical test is simple: rebase freely on commits that exist solely on your own machine; be cautious or avoid it entirely once a branch is shared.

Frequently Asked Questions About Rebase vs Merge Safety

Q1. What is the golden rule of rebasing?

Never rebase commits that have already been pushed to a shared remote repository and might have been pulled by someone else, since doing so creates diverged history that can disrupt collaborators.

Q2. Why does rebasing shared commits cause problems?

Rebasing replaces existing commits with new ones that have different hashes. If a collaborator already has the original commits, your rebased version no longer matches theirs, causing your histories to diverge and requiring a disruptive force push to reconcile.

Q3. Is it safe to rebase commits I've never pushed anywhere?

Yes, this is completely safe. Since no one else has those commits, replacing them with new hashes during a rebase has no effect on anyone else's history, which is why cleaning up your own local branch with rebase before sharing it is a common, low-risk practice.

Q4. When should I prefer merge over rebase?

Prefer merge when you want to preserve an accurate historical record of how branches actually diverged and reunited, or when integrating a branch that's already been shared or reviewed by others, where rewriting its commit hashes could disrupt anyone who already has it.

Q5. What should I do if I need to fix something in a commit that's already been shared with my team?

Rather than rebasing or amending that shared commit, the generally safer approach is to create a brand-new commit that fixes the issue, avoiding any rewriting of history that collaborators may already depend on.

Summary

Consolidating the rebase-versus-merge guidance from throughout this course: rebase is preferable for a clean, linear history when cleaning up your own local commits or keeping a feature branch current before a pull request, while merge is preferable for preserving an accurate historical record or when integrating already-shared branches. Underlying all of this is the golden rule of rebasing: never rebase commits that have already been pushed to a shared remote and might have been pulled by someone else, since rebasing replaces existing commits with new ones bearing different hashes, directly echoing the same risk covered for `git commit --amend` in Module 2. Violating this rule causes a rejected, non-fast-forward push, requiring a force push to override — which can silently erase a collaborator's work built on top of the original, pre-rebase commits. The safe, practical test: rebase freely on local-only, never-pushed commits, and be cautious or avoid rebasing entirely once a branch has genuinely been shared.