refactor: move modules into levels

03_advanced/01-rebasing/README.md

@@ -0,0 +1,130 @@
+# 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.