Search code examples
gitgit-mergegit-rebase

Syncing feature with master using rebase vs merge

According to Atlassian's merge strategy, it is best to merge feature branches back into master with the --no-ff option. This keeps a clean git history on master which allows you to easily see the work that was done in a merge. With that in mind, does it matter if I use rebase or merge when I am merging master into my feature branch?

git merge

Normally, I merge master into my feature branch as I am working on it. This is essentially taking a snapshot of master and putting those changes into my branch. (note, I'm not worrying about merging feature back into master the focus here is the workflow of keeping feature synced with master)

git rebase

The rebase of master into the feature branch is much cleaner and adds adds the changes I have made in the feature branch on top of the head of master.

How does rebase vs merge in this scenario affect...

  1. the process of syncing master to feature?
  2. git history while working on the branch?
  3. git history after the branch is merged with master and deleted?
Solution

    1. With a rebase, you're re-writing history, so you'll have to force-push your feature branch. If you're working with other people, see (2).

    2. Every time you run a rebase, you are effectively re-writing the history of that branch. This is not terrible if it's your own branch and no one is collaborating on it with you, but it can become problematic if multiple developers are contributing to the same branch - in particular because their commits may not cleanly push if you've rewritten the history.

    3. Git history with no rebasing:

      * master
|\
| * branch commit 2
|/|
* | simultaneous commit on master
| * branch commit
|/
* previous commit on master

      vs with rebasing:

      * master
|\
| * branch commit 3
| * branch commit 2
| * branch commit
|/
* simultaneous commit on master
* previous commit on master

      as you can see, the history might be a little less complex when you rebase your branch, and some people prefer it for this reason.

    Some additional color: When I decide whether a rebase is appropriate, I often think about whether I consider the branch to have been "published". A "published" branch is one that other developers might have done work on, and would reasonably expect not to change. An "unpublished" branch is one that I'm using to organize my changes into one or more commits, and haven't shared with other developers yet. It's a draft of my work.