CHAPTER 07
Rebasing and Conflict Resolution
Updated: May 15, 2026
25 min read
# CHAPTER 7
Rebasing and Conflict Resolution
1. Introduction
Whilegit merge is the safest way to combine code, many enterprise engineering teams forbid it. Merging creates "Merge Commits" which, over time, cause the project's history graph to look like a chaotic, tangled spiderweb. The alternative is Rebasing. Rebasing rewrites history to create a perfectly linear, clean timeline. However, because rebasing literally unplugs your commits and replugs them somewhere else, resolving conflicts during a rebase is significantly more complex and dangerous than during a standard merge. In this chapter, we will master the git rebase command and navigate the unique challenges of rebase conflicts.
2. Learning Objectives
By the end of this chapter, you will be able to:- Understand the architectural difference between Merge and Rebase.
-
Execute a
git rebaseoperation.
- Understand why a single rebase can trigger *multiple* conflicts.
-
Resolve a rebase conflict and use
git rebase --continue.
- Understand the Golden Rule of Rebasing (never rebase public history).
3. Beginner Explanation
Imagine you are building a Lego tower (Your Branch) next to the main Lego castle (main).
- Merging: You build a bridge connecting the top of your tower to the top of the castle. You leave your tower exactly where it was. (Creates a messy bridge).
- Rebasing: You grab the entire baseplate of your tower. You pick it up, walk over to the castle, and snap the very bottom of your tower onto the very top of the castle. Your tower now looks like it was part of the castle all along. (Creates a clean, single line).
4. The Mechanics of Rebase
When you are on yourfeature branch and type git rebase main, Git does the following:
-
1.
It unplugs all the unique commits you made on the
featurebranch and temporarily saves them in memory.
-
2.
It fast-forwards your
featurebranch to perfectly match the newest version ofmain.
-
3.
It takes your saved commits and "replays" them, one by one, on top of the new
main.
The Danger: If your feature branch has 5 commits, Git has to apply them 1 by 1. If commit #2 conflicts with the new main, the rebase pauses. You fix the conflict. Then it applies commit #3. If commit #3 conflicts, it pauses *again*. A single rebase can require you to resolve conflicts multiple times!
5. Resolving a Rebase Conflict
When a rebase halts due to a conflict, the terminal output is different than a standard merge:
text
The Rebase Resolution Workflow:
- 1. Open the conflicted file and resolve it (just like Chapter 5 or 6).
-
2.
Stage the file:
git add index.html
-
3.
CRITICAL DIFFERENCE: Do NOT type
git commit!
-
4.
Type:
git rebase --continue
Git will then take your fixed file, successfully attach that commit, and immediately try to apply the *next* commit in the queue.
6. Mini Project: Resolve Conflicts During Rebase
Let's simulate the rebase conflict loop.Step-by-Step Walkthrough:
-
1.
Assume
mainhas a fileapp.jswithlet version = 1.0;.
-
2.
You create
feature-branch. You change it tolet version = 2.0;and commit. You then add a second commit changing it tolet version = 3.0;.
-
3.
Meanwhile, your coworker changes
maintolet version = 1.5;.
-
4.
On
feature-branch, rungit rebase main.
-
5.
Conflict 1: Git tries to apply your
2.0commit over the1.5main commit. It fails.
-
6.
Open
app.js, fix it to be2.0, and rungit add app.js.
-
7.
Run
git rebase --continue.
-
8.
Conflict 2: Git now tries to apply your
3.0commit over the2.0code. It might fail again depending on the surrounding text!
-
9.
If it fails, fix it,
git add, andgit rebase --continue.
-
10.
Finally, Git will say
Successfully rebased and updated refs/heads/feature-branch.
7. The Golden Rule of Rebasing
Rebasing rewrites history. The SHA hashes of your commits physically change. Golden Rule: NEVER rebase commits that you have already pushed to a public repository that other people are working on. If you rebase the publicmain branch, you will destroy the history for every other developer on your team, causing catastrophic sync errors across the entire company. You should only ever rebase your *own local, private feature branches*.
8. Best Practices
-
Squashing Before Rebasing: If you have 20 messy "work in progress" commits on your feature branch, rebasing might cause 20 separate conflicts. Before you rebase onto
main, use Interactive Rebasing (git rebase -i) to squash those 20 commits into 1 single, clean commit. Then, when you rebase ontomain, you will only have to resolve conflicts a maximum of one time.
9. Common Mistakes
-
The Accidental Commit: During a rebase conflict resolution, developers often fall back on muscle memory and type
git commitaftergit add. This breaks the rebase state machine. You must retrain your muscle memory: when rebasing, the workflow is ALWAYSgit add->git rebase --continue.
10. Exercises
- 1. Explain the operational difference between the command used to conclude a standard Merge conflict versus a Rebase conflict.
-
2.
Why is it highly dangerous to perform a
git rebaseon a public branch (likemain)?
11. FAQs
Q: I got completely lost in a rebase conflict loop and ruined my code. How do I escape? A: Just like a merge, rebase has a panic button. Typegit rebase --abort. This instantly cancels the rebase, throws away all your partial fixes, and returns your branch to exactly how it looked before you typed the rebase command.
12. Summary
In Chapter 7, we graduated to advanced history management. We understood that while Rebasing provides the immense benefit of a perfectly clean, linear commit history, it demands a higher level of operational discipline. We learned that rebasing replays commits sequentially, creating the possibility of a multi-stage conflict loop. By mastering thegit rebase --continue workflow and strictly adhering to the Golden Rule of never rebasing public history, we equipped ourselves to maintain enterprise-grade repository hygiene.