git rebase basic usage - Deep Dive

Overview - git rebase basic usage

What is it?

Git rebase is a command that lets you move or combine a sequence of commits to a new base commit. It helps you keep your project history clean and linear by replaying your changes on top of another branch. Instead of merging branches with a merge commit, rebase rewrites the commit history as if your work started from the latest point of the target branch.

Why it matters

Without rebase, your project history can become cluttered with many merge commits, making it hard to follow the actual changes. Rebase solves this by creating a straight line of commits, which makes understanding the project history easier and helps avoid conflicts later. This is especially important when multiple people work on the same codebase.

Where it fits

Before learning git rebase, you should understand basic git concepts like commits, branches, and merges. After mastering rebase, you can explore advanced git workflows, conflict resolution during rebase, and interactive rebasing for editing commits.

Mental Model

Core Idea

Git rebase moves your changes to start from a new base, rewriting history to create a clean, straight line of commits.

Think of it like...

Imagine you wrote a story starting from page 5, but then you realize you should have started from page 10. Rebase is like cutting out your pages and pasting them after page 10, so the story flows smoothly without confusing jumps.

Current branch: A---B---C (your commits)
Target branch: D---E---F (new base)

After rebase:
D---E---F---A'---B'---C'

(A', B', C' are your commits replayed on top of F)

Build-Up - 7 Steps

1

Foundation

Understanding commits and branches

Concept: Learn what commits and branches are in git and how they represent changes and lines of work.

A commit is like a snapshot of your project at a point in time. A branch is a pointer to a commit and represents a line of development. When you create a branch, you start a new line of work from a commit.

Result

You can see your project history as a series of commits connected by branches.

Understanding commits and branches is essential because rebase works by moving commits between branches.

2

Foundation

What is merging in git

Concept: Learn how git merges combine two branches by creating a new commit that joins their histories.

When you merge a branch into another, git creates a new commit called a merge commit. This commit has two parents and shows that two lines of work have joined.

Result

Your project history shows branches joining with merge commits, which can make the history look like a tree with branches.

Knowing how merge works helps you understand why rebase offers a different way to combine work.

3

Intermediate

Basic git rebase command usage

Concept: Learn how to use the git rebase command to move your commits onto another branch.

Suppose you are on a feature branch branched from main. To update your feature branch with the latest main changes, run: $ git checkout feature $ git rebase main This moves your feature commits to start after the latest commit on main.

Result

Your feature branch history is rewritten to appear as if you started from the latest main commit.

Using rebase this way keeps your feature branch up to date without merge commits, making history linear.

4

Intermediate

Handling conflicts during rebase

🤔Before reading on: do you think git automatically resolves all conflicts during rebase, or do you need to fix some manually? Commit to your answer.

Concept: Learn that conflicts can happen during rebase and how to resolve them.

If your changes and the target branch changed the same lines, git pauses rebase and asks you to fix conflicts. You fix the files manually, then run: $ git add $ git rebase --continue To keep going. You can also abort the rebase with: $ git rebase --abort if you want to cancel.

Result

After resolving conflicts and continuing, your commits are replayed cleanly on the new base.

Knowing how to handle conflicts during rebase is crucial to safely rewriting history without losing work.

5

Intermediate

Difference between rebase and merge

🤔Before reading on: does rebase create a merge commit like merge does? Commit to your answer.

Concept: Understand how rebase and merge differ in combining branches.

Merge combines branches by creating a new commit with two parents, preserving history as a graph. Rebase rewrites your commits to start from the new base, creating a linear history without merge commits. Both achieve similar goals but produce different histories.

Result

You can choose rebase for a clean history or merge to preserve the exact branching structure.

Understanding this difference helps you pick the right tool for your workflow and collaboration style.

6

Advanced

Rebase to keep feature branch updated

🤔Before reading on: do you think rebasing a feature branch on main changes the commit hashes? Commit to your answer.

Concept: Learn how rebasing a feature branch on main keeps it updated and why commit hashes change.

When you rebase your feature branch onto main, git replays your commits on top of main's latest commit. This creates new commits with new hashes because the parent commit changed. This means your branch history looks like it started from the latest main commit.

Result

Your feature branch is up to date with main, and history is linear, but commit hashes differ from before rebase.

Knowing that rebase rewrites commits and changes hashes explains why you should avoid rebasing shared branches.

7

Expert

Risks and best practices with rebase

🤔Before reading on: is it safe to rebase commits that others have already pulled? Commit to your answer.

Concept: Learn the dangers of rebasing shared commits and how to use rebase safely in teams.

Rebasing rewrites history, changing commit hashes. If others have based work on your commits, rebasing and pushing rewritten commits causes confusion and conflicts. Best practice is to only rebase local or private branches before sharing. For shared branches, use merge or coordinate carefully.

Result

Avoiding rebasing shared commits prevents broken collaboration and lost work.

Understanding the impact of rewriting history protects your team from complex git problems.

Under the Hood

Git stores commits as snapshots with references to parent commits. Rebase works by finding the common ancestor of your branch and the target branch, then applying each of your commits one by one onto the target branch's latest commit. This creates new commits with new hashes because the parent commit changes. Git uses a temporary area to replay commits and stops if conflicts occur.

Why designed this way?

Rebase was designed to provide a way to keep history linear and clean, making it easier to understand and navigate. The alternative, merge, preserves history but can clutter it with many merge commits. Rebase trades off rewriting history for clarity, which is useful in many workflows but requires care.

Original history:

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

Rebase process:
1. Find common ancestor (D)
2. Replay A, B, C on top of F

Result:

main:    D---E---F
                 
feature:          A'---B'---C'

(A', B', C' are new commits with new hashes)

Myth Busters - 4 Common Misconceptions

Quick: Does git rebase preserve the original commit hashes? Commit yes or no before reading on.

Common Belief: Rebase keeps the original commits exactly as they are, just moves them.

Reality: Rebase creates new commits with new hashes because it changes the parent commit, effectively rewriting history.

Why it matters: Thinking hashes stay the same leads to rebasing shared branches, causing conflicts and confusion in collaboration.

Quick: Can you safely rebase a branch that others have already pulled? Commit yes or no before reading on.

Common Belief: It's always safe to rebase any branch, even if others use it.

Reality: Rebasing shared branches rewrites history and breaks others' work who based their work on the original commits.

Why it matters: Misusing rebase in shared branches can cause lost work and complicated merges.

Quick: Does rebase automatically resolve all conflicts? Commit yes or no before reading on.

Common Belief: Git rebase automatically fixes all conflicts during replay.

Reality: Git stops and asks you to manually fix conflicts before continuing the rebase.

Why it matters: Assuming automatic conflict resolution can cause confusion and incomplete rebases.

Quick: Does rebase create a merge commit like git merge? Commit yes or no before reading on.

Common Belief: Rebase creates a merge commit to combine branches.

Reality: Rebase rewrites commits to create a linear history without merge commits.

Why it matters: Confusing rebase with merge leads to misunderstanding project history and workflow choices.

Expert Zone

1

Rebasing changes commit hashes, so any references to those commits (like pull requests or issue links) may become outdated.

2

Interactive rebase allows editing, reordering, and squashing commits, giving fine control over history beyond basic rebase.

3

Rebase can be combined with autosquash to automatically fixup commits during interactive rebase, streamlining cleanup.

When NOT to use

Avoid rebasing branches that have been pushed and shared with others to prevent rewriting public history. Instead, use git merge for shared branches. Also, avoid rebasing very large branches with many conflicts; consider merging to reduce risk.

Production Patterns

Teams often use rebase to keep feature branches updated with main before merging, ensuring a clean history. Interactive rebase is used to polish commits before code review. Some projects enforce linear history by requiring rebasing or fast-forward merges.

Connections

Version Control Systems

Git rebase is a feature within version control systems that manage changes over time.

Understanding rebase deepens your grasp of how version control tracks and rewrites history, a core concept in software development.

Conflict Resolution

Rebase often requires manual conflict resolution when changes overlap.

Mastering rebase improves your skills in resolving conflicts, a critical part of collaborative work.

Storytelling and Editing

Rebase is like editing a story to improve flow and clarity by rearranging scenes.

Seeing rebase as story editing helps appreciate why clean history matters for understanding project evolution.

Common Pitfalls

#1 Rebasing a branch that others have already pulled and based work on.

Wrong approach:

$ git checkout feature
$ git rebase main
$ git push origin feature --force

Correct approach:

Coordinate with team before rebasing shared branches or use merge instead:
$ git checkout feature
$ git merge main
$ git push origin feature

Root cause:

Misunderstanding that rebasing rewrites history and changes commit hashes, breaking others' work.

#2 Ignoring conflicts during rebase and forcing continuation.

Wrong approach:

$ git rebase main
# conflict occurs
$ git rebase --continue
# without fixing conflicts

Correct approach:

$ git rebase main
# conflict occurs
# manually fix conflicts in files
$ git add
$ git rebase --continue

Root cause:

Assuming git automatically resolves conflicts and not manually fixing them.

#3 Using rebase to combine unrelated branches or histories.

Wrong approach:

$ git checkout feature
$ git rebase unrelated-branch

Correct approach:

Use git merge or cherry-pick for unrelated branches:
$ git checkout feature
$ git merge unrelated-branch

Root cause:

Misunderstanding that rebase expects a common ancestor and linear history.

Key Takeaways

Git rebase moves your commits to a new base, rewriting history to create a clean, linear project timeline.

Rebase helps keep your feature branches up to date without cluttering history with merge commits.

Conflicts during rebase must be resolved manually before continuing the process.

Never rebase commits that have been shared with others to avoid breaking collaboration.

Understanding rebase deeply improves your ability to manage project history and collaborate effectively.