Rebase vs merge
Overview
Merge and rebase are two different ways to combine code from one Git branch into another. Imagine you are writing a chapter for a book. While you are writing, the editor adds a new introduction to the master copy. You need to combine your chapter with the new introduction. - **Merge**: You take the new introduction, put it at the very end of your work, and staple a note saying "I combined the two versions here." (This creates a 'merge commit'). - **Rebase**: You take your chapter, magically rewind time to *after* the editor added the introduction, and cleanly attach your chapter to the end. (This rewrites history to make it a straight line). The rule is: **merge preserves history exactly as it happened, while rebase rewrites history to make it look like a clean, straight line.**
Teams use `merge` because it is safe and never deletes history. Advanced teams use `rebase` because a straight-line history is much easier to read when hunting for bugs later.
Where used: Git, GitHub Pull Requests
Why learn this
- You will understand why senior engineers ask you to 'rebase your branch' before merging a pull request.
- You will avoid destroying your team's code history with bad rebases.
Code walkthrough
def show_history():
print('Merge history: A -> B -> (Merge C+B)')
print('Rebase history: A -> B -> C (Straight line)')
show_history()Focus: print('Rebase history: A -> B -> C (Straight line)')
Aha moment
history = ['commit1', 'commit2']
# Rebase rewrites the past:
history = ['commit1', 'new_main', 'commit2_rewritten']
print(history)Prediction: In a rebase, do your old commits stay exactly the same?
Common guess: Yes, they just move.
No, rebase literally creates brand new commits with new ID numbers to replace the old ones. That is why it 'rewrites history'.
Common mistakes
- Rebasing a public branch: You rebase a branch that other teammates are already using. Because rebase rewrites history, their local copies become instantly broken and out of sync.
- Panicking during rebase conflicts: Rebase applies your commits one by one. If you hit a conflict, you might have to fix it multiple times. Beginners often panic and abort.
Recall questions
- Explain the difference between merge and rebase in your own words, as if to a classmate.
- Why is it dangerous to rebase a branch that other people are using?
Understanding checks
You want to update your private feature branch with the latest code from `main`. You use `git rebase main`. Will this create a new 'merge commit'?
No. Rebase rewrites your commits to sit neatly on top of main, creating a straight line of history without a merge commit.
Merge preserves history exactly as it happened (with a merge commit), while rebase rewrites history to make it look like a clean, straight line.
You and a teammate are both committing directly to the `shared-fixes` branch. You pull the latest code. Should you use merge or rebase?
You should use merge.
Never rebase a public branch. Because your teammate is also using the branch, rebasing would rewrite the history they rely on, breaking their local repository.
Practice tasks
Identify the strategy
Given this simulator, change the string to state whether this represents a 'merge' or a 'rebase' based on the straight line.
Challenge
Simulate history rewriting
Write a Python function `simulate_rebase(main_commits, feature_commits)` that takes two lists. It should return a new list containing all `main_commits` followed by all `feature_commits`, mimicking how rebase places your work at the very tip of history.