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:

Review the current commit history
Rebase the feature branch onto main
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.