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?

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.

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.