# 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

```bash
# 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 checkout <branch-name>
```

## Verification

Run the verification script to check your solution:

```bash
.\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.