git-workshop/02_advanced/01-rebasing/README.md

Module 07: Rebasing

Learning Objectives

By the end of this module, you will:

• Understand what rebasing is and how it works
• Know the difference between merge and rebase
• Perform a rebase to integrate changes from one branch to another
• Understand when to use rebase vs merge
• Know the golden rule of rebasing

Challenge Description

You have a repository with a main branch and a feature branch. While you were working on the feature branch, new commits were added to main. You want to incorporate those changes into your feature branch while maintaining a clean, linear history.

Your task is to:

1. Review the current commit history
2. Rebase the feature branch onto main
3. Verify that the history is now linear

Key Concepts

What is Rebasing?

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Instead of creating a merge commit like git merge does, rebasing rewrites the commit history by replaying your commits on top of another branch.

Rebase vs Merge

Merge:

    A---B---C feature
   /         \
  D---E---F---G main

Creates a merge commit (G) that ties the histories together.

Rebase:

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

Replays commits A, B, C on top of F, creating new commits A', B', C' with the same changes but different commit hashes.

Benefits of Rebasing

• Cleaner history: Linear history is easier to read and understand
• Simpler log: No merge commits cluttering the history
• Easier bisecting: Finding bugs with git bisect is simpler with linear history

The Golden Rule of Rebasing

Never rebase commits that have been pushed to a public/shared repository.

Why? Because rebasing rewrites history by creating new commits. If others have based work on the original commits, rebasing will cause serious problems for collaborators.

Safe to rebase:

• Local commits not yet pushed
• Feature branches you're working on alone
• Cleaning up your work before creating a pull request

Never rebase:

• Commits already pushed to a shared branch (like main or develop)
• Commits that others might have based work on

Useful Commands

# Rebase current branch onto another branch
git rebase <branch-name>

# View commit history as a graph
git log --oneline --graph --all

# If conflicts occur during rebase:
# 1. Resolve conflicts in files
# 2. Stage the resolved files
git add <file>
# 3. Continue the rebase
git rebase --continue

# Abort a rebase if something goes wrong
git rebase --abort

# Check which branch you're on
git branch

# Switch to a branch
git switch <branch-name>

Verification

Run the verification script to check your solution:

.\verify.ps1

The verification will check that:

• You're on the feature branch
• The rebase was completed successfully
• The history is linear (no merge commits)
• All commits from both branches are present

Tips

• Always check your commit graph with git log --oneline --graph --all before and after rebasing
• If you encounter conflicts during rebase, resolve them just like merge conflicts
• Use git rebase --abort if you want to cancel the rebase and start over
• Rebasing rewrites history, so the commit hashes will change
• Only rebase local commits that haven't been shared with others

When to Use Rebase vs Merge

Use Rebase when:

• You want a clean, linear history
• Working on a local feature branch that hasn't been shared
• Updating your feature branch with the latest changes from main
• You want to clean up commits before submitting a pull request

Use Merge when:

• Working on a shared/public branch
• You want to preserve the complete history including when branches diverged
• You're merging a completed feature into main
• You want to be safe and avoid rewriting history

What You'll Learn

Rebasing is a powerful tool for maintaining a clean project history. While merging is safer and preserves exact history, rebasing creates a more readable linear timeline. Understanding both techniques and knowing when to use each is essential for effective Git workflow management.