Git Merge No Fast-forward Flag - Bad Practice?

Question

I have a question with regards to a flag which can be used with the merge command in Git. Apparently, if you use --no-ff with merge (no fast-forward flag), it will create a new commit object at the point of the merge, even if the merge could have been performed via a fast-forward.

git merge --no-ff afeature

I have not found any information on that flag and nobody seems to discuss it anywhere. Is it bad practice to create such a commit object (and thus avoid losing information about the historical existence of the feature)? Or is it out of date and been replaced by something?

Deformed

Newer Git automatically merges non-fast-forward when you issue a pull. – Riesling

"and thus avoid losing information" -- Regardless of whether a merge commit is created, the original commits become part of the history of the current branch. The only case where information would be "lost" would be by a fast-forward merge: the details of when the commits were merged would not be recorded. – Misshapen

Answer 1

No - this is not bad practice. It is a choice you have. One situation in which forcing the creation of a merge commit is useful is in code review. If developers always push feature branches for review and the reviewer performs the merge when the feature is accepted then the merge commit contains all the information about who did the review along with additional comments which can be useful. This is how the pull-request style workflow used for github/gitlab works. When the project owners accept a pull request, a merge commit is always created even if it was capable of fast-forward merging.

Schaub

Answer 2

I've heard both sides of this one and I generally favour them for readability's sake. On the other side here is (someone else's, not mine) opinion in some detail.

Trapezius

Answer 3

Yes indeed a bad practice. There may be exceptions.
Rule is (generally):

• Rebase from main to feature
• Fast forward merge from feature to main.

Rebase will bring all commits of your colleagues to your feature branch. Once you rebase, fast forward merge will merge (before anyone else can merge, or else repeat process). You should never need no FF merge.

Advowson