gitgit-mergegit-rebase

What's the difference between git rebase and merge --no-ff

Both approach seem to have the same purpose to have clean history:

So, if I have done rebasing on a feature branch, do I still need --no-ff when merging back to the main branch?

UPDATE:

It seems to me there is a confusion between rebasing, fast forward and non fast forward merging, basically diagram (fig 3.28) in this link http://git-scm.com/book/en/Git-Branching-Rebasing shows normal merge result is the same as merge --no-ff from the top answer of this link Why does git perform fast-forward merges by default?

Solution

  • It depends how you want your history to look.

    A really simple example:

    git merge --no-ff

    *   33ad16c (HEAD, master) Merge branch 'feature-1'
|\  
| * e61c6a6 Various bug fixes
| * e15a356 Started feature
|/  
* 38b8ada Initial commit

    git rebase

    * e61c6a6 (HEAD, master) Various bug fixes
* e15a356 Started feature
* 38b8ada Initial commit

    These two histories reflect the exact same commits but using the --no-ff, the first history makes it really clear how 2 of the commits where, in fact, part of the same set of work. This allows you to know exactly what work went into what feature. This makes it easier to roll back changes or just give yourself context when navigating the history.

    The rebase history does not show this distinction and it makes it impossible to see any grouping of work. It makes it look like everyone is committing to master.

    The empty merge commit you get with --no-ff also gives a helpful place to hang a commit message, whereas a plain commit gives you no easy place to say "This commit merges in the work for feature-x", which again is helpful for history