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

Question

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

• Git Rebase

• No fast forward (--no-ff)

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 fast-forward merges by default?

Solution 1

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

Solution 2

Generally if you merge some feature branch you want to use --no-ff to enforce the creation of an explicit merge commit.

If you are just doing your work on some branch you generally want to avoid merge commits that might arise from a git pull. Therfore you use git rebase or git pull --rebase to not create a merge commit and get a clean history.

Comments

[Özgür Eroğlu]

This link may help stackoverflow.com/questions/2850369/…

[James Lin]

There is a confusion between rebasing, fast forward and non fast forward merging, in this link git-scm.com/book/en/Git-Branching-Rebasing the result of normal merging (fig 3.28) contradicts the explanation of the top answer (see diagram) stackoverflow.com/questions/2850369/…

[joel]

"impossible to see any groupings of work" ... you could of course tag related commit messages e.g. with ticket nos if you're using them (which has other benefits)