When to use the '--no-ff' merge option in Git -

a successful git branching model recommends use --no-ff when merging branches:

the --no-ff flag causes merge create new commit object, if merge performed fast-forward. avoids losing information historical existence of feature branch , groups commits added feature. […]

yes, create few more (empty) commit objects, gain bigger that cost. unfortunately, have not found way make --no-ff default behavior of git merge yet, should be.

understanding git workflow, however, recommends not use --no-ff:

so add new rule: “when merge in feature branch, use –-no-ff force new commit.” gets job done, , move on. […]

the --no-ff band-aid, broken bisect, , blame mysteries symptoms you’re using screwdriver hammer. […]

both approaches seem reasonable difference scenarios, considered "good practice?"

when use --no-ff, when not, why?

it's dependent on you're trying do. rule of thumb if merge "means something" use --no-ff option. when merge doesn't mean , might have used rebase there's no reason use --no-ff

the thing git it's powerful tool, , can use in many ways - of not wrong. asking what's "right way" asking what's right way paint picture.

at least me it's evolving set of ways it, frequent discussions in team of how want collaborate on code - try derive kind of "how it's done here" standard, it's our way of doing it.