When you are working on a feature branch for more than a day, the “ground” (the main branch) usually moves beneath your feet. Other developers are merging their PRs, and your branch is becoming increasingly outdated.
Step #3 is about bringing those new main changes into your feature branch so you don’t have a “Merge Conflict Nightmare” at the end of the week.
1. Merging vs. Rebasing
There are two ways to get the latest main code into your feature branch.
Option A: The Merge (git merge main)
This takes all the new changes from main and ties them into your branch with a single “Merge Commit.”
- The Visual: Your branch history stays exactly as it was, but you see a new commit where
mainwas joined in. - Pros: It is non-destructive. Your history is a literal record of what happened and when.
- Cons: If
mainmoves frequently, your branch history gets cluttered with “Merge branch ‘main’ into feature” commits.
Option B: The Rebase (git rebase main)
This “lifts” your unique commits, moves the starting point of your branch to the very tip of the current main, and then reapplies your commits one by one on top.
- The Visual: It looks like you started your work today on the latest version of
main. It creates a perfectly straight line of history. - Pros: Clean, readable history. No “junk” merge commits.
- Cons: It rewrites history. Your commit hashes will change.
2. The Risks
| Method | The Major Risk | Why it happens |
| Merge | The “Merge Web” | If many people merge back and forth, the git log --graph becomes a “spaghetti” mess that is impossible to read. |
| Rebase | The “Force Push” Trap | Since Rebasing changes commit hashes, if you already pushed your branch to GitHub, you’ll have to git push --force. Never rebase a branch that other people are also working on. |
The “Golden Rule” of Rebasing
Never rebase a public branch.
If you are the only one working on
feature/fix-set-e, rebase all you want. If a teammate is also pulling that branch to help you, stick to merging.
3. Handling Multiple Branches
If you have feature/A and feature/B both active, you have to manage them individually:
- Update Local Main:
git checkout main->git pull - Sync Branch A:
git checkout feature/A->git rebase main - Sync Branch B:
git checkout feature/B->git rebase main
Note: If feature/B actually depends on code inside feature/A, you can rebase B onto A instead of main. However, this gets complex quickly and is usually a sign that your features should have been one single PR.
Which one should you use?
- Use Merge if you are a beginner or working in a highly collaborative “long-lived” branch. It’s safer because you can’t “lose” history.
- Use Rebase if you want a professional, clean commit history and you are the sole owner of your feature branch.