131 lines
4.1 KiB
Markdown
131 lines
4.1 KiB
Markdown
# 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 switch <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.
|