Git tips & tricks: Merge vs Rebase (When to use?)

Keeping a clean history and smooth git workflow comes down to knowing the base use-cases & rules.

Rebases are how changes should pass from the top of hierarchy downwards and merges are how they flow back upwards.

---

• Use git pull --rebase when pulling changes from origin.
• Use git merge when merging feature branch changes back to master.

Rebasing Deletes Merge Commits! Never rebase master onto your feature branch!
see also –preserve-merges flag.

---

Using merge when pulling changes from origin ties two histories together creating interleaved messy thread of histories:

• Interleaved history during merge: their feature X, my feature Y, their feature X, my feature Y...
• Linear history during rebase: their feature X, their feature X, my feature Y, my feature Y...

---

Should I Merge or Rebase

A clean history in git comes down to knowledge when to use merge vs. rebase:

• When pulling changes from origin/develop onto your local develop use rebase.
• When finishing a feature branch merge the changes back to develop.

---

Scenario #1

You have no any changes in your local develop branch and you want to pull changes from origin/develop:

No problems. git pull and git pull --rebase will produce the same results.

---

Scenario #2

You have few small changes in your own local _develop branch that have not yet been pushed. You want to pull all missing changes from origin/develop to your local develop before pushing your changes.

During merge two histories tie together in a mixed way. And if you will merge few times you would have a messy history In result.

To have a linear commit history after pushing use git pull –rebase. During the rebase your local commits are applied in order on top of the changes you pulled from origin/develop.

When you `rebase` your branch onto their branch, you tell Git to make it look as though you checked out their branch cleanly, then did all your changes starting from there.

Use git merge during the merging a feature branch back into develop before pushing to origin/develop.

---

Scenario #3

You have few small changes in your own local _develop branch that have not yet been pushed. You've decided to make some small refactoring into separate local temporary branch, that should precede your changes.

After refactoring is finished in your tmp_local_refactoring branch you checkout into your feature branch and make git rebase onto your tmp_local_refactoring branch in order to have exactly same history as you worked only in your feature branch all the time.

---

Conclusions

Merging is a safe option that preserves the entire history of your repository, while rebasing creates a linear history by moving your feature branch onto the tip of master.

• Use git rebase when pulling changes from master.
• Use git rebase during the work with the local temporary branches. Rebase onto your tmp branch to have a linear history into your actual one.
• Never use git rebase on public branches. Always use git merge during the merging a feature branch back into master before pushing your changes to origin.

If you’re not entirely comfortable with git rebase, you can always perform the rebase in a temporary branch. That way, if you accidentally mess up your feature’s history, you can check out the original branch and try again.

---

see Also

• Git Tips & Tricks: Case-sensitive Only filename changes
• Git Tips & Tricks: Change Git Comments (Git Commit message)
• Git tips & trics: Reverting the Changes
• Attlasian - Marge vs Rebase
• Stackoverflow - The Difference Between Rebase & Merge