4. Advanced Git Concepts & Collaboration 4a Rebasing Git rebase is a powerful feature that allows you to rewrite commit history by applying your branch's commits on top of another branch's latest commits. Instead of creating a merge commit, rebase integrates changes by replaying your commits sequentially onto the target branch.
Basic Rebase Command git rebase [branch-name] This command takes all the commits from your current branch that aren't in the target branch and reapplies them on top of the target branch's latest commits.
Visual Example Let's say you have this commit history: main: A---B---C---D \ feature: E---F---G After running git checkout feature && git rebase main, your history becomes:
main: A---B---C---D \ feature: E'--F'--G' Where E', F', and G' are the same changes as E, F, and G but applied on top of D.
Rebase vs Merge When to Use Rebase:
For feature branches before merging into main When you want a cleaner, linear commit history To keep your branch up-to-date with the latest changes from main When to Use Merge:
When you want to preserve the actual history of when merges occurred When working with shared branches that others are working on For historical records showing where features were integrated Rebase Example Let's walk through a complete rebase example:
1 Create and switch to main branch: git checkout main git pull origin main
Edit file1.js and commit git add file1.js git commit -m "Add login form validation"
Edit file2.js and commit git add file2.js git commit -m "Implement password strength check" 4 Meanwhile, main branch gets updated:
On main branch git checkout main git pull origin main # New commits added to main git checkout feature/new-login 5 Rebase feature branch onto latest main: git rebase main
6 Your history now looks like:
main: A---B---C---D---E---F \ feature: G'--H' 7 Now merge into main (clean history):
git checkout main git merge feature/new-login Interactive Rebase You can also use interactive rebase to edit, squash, or reorder commits:
git rebase -i [commit-hash] This opens an editor showing your commits with commands like:
pick - keep the commit squash - combine with previous commit edit - modify commit message or content drop - remove commit Important Caution: Never Rebase Shared Branches If you've already pushed a branch to a shared remote repository, rebasing changes that others might have based on can cause problems for other developers. This is because:
It rewrites the commit history Others' local copies will be out of sync It can cause conflicts or loss of work Rebase with Remote Branches If you need to rebase a shared branch, consider using git push --force-with-lease (which is safer than --force) after the rebase, but this should only be done when you're certain no one else is working on that branch.
Can you answer the Questions 1. What is the main difference between git rebase and git merge in terms of commit history? 2. Why is it dangerous to rebase branches that have been pushed to a shared remote repository? 3. How does the commit history look different after using git rebase compared to git merge? 4. What command would you use to perform an interactive rebase on your last 3 commits? 5. What are some benefits of using rebase for feature branches before merging into main? 6. When might you want to avoid using rebase and instead use merge? 7. How can you check if your branch has been rebased from the main branch before merging? 8. What happens to commit messages when you perform an interactive rebase with the squash command? 9. Can you explain what git rebase -i HEAD~3 does? 10. What is the purpose of using git push --force-with-lease after rebasing a shared branch? 11. Why might you want to use rebase to keep your feature branch up-to-date with main? 12. What are the risks involved in rebasing commits that others may have already pulled? 13. How does git determine which commits to replay during a rebase operation? 14. What happens if there are conflicts during a rebase operation? 15. Can you rebase a branch that has already been merged into another branch?