Hi If we use squash we will lose some context and occasionally, we need multiple small features combined into one big release. We would rather not mix it into one monolithic non-readable blob. For us, sometimes it is better to rebase something to make history more accurate than squash everything into one commit. We can use squash only for one story. Anyway, squash is a different feature. Same as rebase (of course we're doing the rebase before merge to clarify history and to make some regression tests) Then we have a set of branches. Some branches contain only one commit. For example, we have 4 branches: - two commits - one commit - one commit - three commits With --no-ff (only merges) we have next graph with extra merges (E', F') for branches with one commit B---C E F G---H---I / \ / \ / \ / \ A-------D---E'--F'----------J With --ff (fast-forward everything) we miss merge branches (D, J) and it's harder to fast revert some problematic releases properly, because it's not clear that commits G-H-I - is one release A---B---C---E---F---G---H---I Story which --ff-one-only should build without manual control B---C G---H---I / \ / \ A-------D---E---F-----------J There we have merge commits (D, J) only for complex branches. Branches E and F fast-forwarded to prevent extra merges. Sorry if my explanation isn't clear enough -- Ruslan
