How would you decide between fast-forward, --no-ff merge commits, and squash merges for a shared Git branch?

## Frame the question before answering it There is no universally correct topology, so the useful answer names the properties history is being optimised for and shows what each option costs. Four properties do most of the work: **readability of the log**, **revert granularity**, **bisect behaviour**, and **re-merge correctness**. ## Option 1 — fast-forward wherever possible Each branch's commits land inline; nothing marks where a branch started or ended. `git log --oneline` is a straight sequence, and every commit is an independent step for `git bisect`, which is the finest granularity you can get when hunting a regression. What you give up is grouping. Nothing in the graph says these six commits were one change, so reverting a feature means reverting each commit individually in reverse order. Enforcing this shape means contributors must rebase their branch onto the tip before integrating, which rewrites their commit ids and demands force-push discipline on the branch. `merge.ff = only` makes non-fast-forward merges fail loudly instead of quietly producing merge commits. ## Option 2 — always record a merge commit (--no-ff) Every integration becomes a two-parent commit. The benefits are concrete: - `git log --first-parent` walks only the mainline and shows exactly one entry per integrated branch — a changelog you did not have to write. - `git revert -m 1 <merge>` removes the whole feature in one commit, because the merge is the single point where it entered. - The branch's individual commits stay reachable, with authorship and rationale intact. The costs: a denser `--graph` view, merge commits that show no diff against their second parent (which confuses newcomers), and bisect that can descend into a branch's intermediate commits, some of which may not build. `merge.ff = false` makes it the default. ## Option 3 — squash each branch into one commit One commit per unit of work: the log is as readable as it gets, and review-churn commits never reach the shared branch. The costs are real and specific. The intermediate commits and their per-commit authorship are not part of the shared branch, so blame attributes everything to the squash. Bisect can only narrow a regression to the whole feature. And because the squash commit has no parent link to the branch, the merge base does not advance: `git branch --merged` never lists the branch, and merging it again replays already-integrated work. A squash policy is only coherent when paired with a rule that a branch is retired as soon as it is squashed in. ## How I would actually decide - **How large is a typical branch?** If branches are one or two commits, the three options barely differ and I would take the simplest — fast-forward. If branches routinely carry ten meaningful commits, squashing destroys information that took effort to create. - **How is the code reverted in an incident?** If the realistic recovery action is "back out that whole feature", `--no-ff` pays for itself the first time it is used. - **How disciplined is commit hygiene?** Squashing is a good shield for branches full of "wip" and "fix review" commits; it is a poor fit for authors who curate each commit deliberately. - **Does anything depend on the shape?** Release-note generation, changelog scripts and audit trails often read `--first-parent`, which only means something under a merge-commit policy. ## Making the decision stick A policy that lives in a wiki page is not a policy. Express it where Git can act on it: `merge.ff` in repository or user config for the default, `--ff-only` in the habits and scripts people run, and, on infrastructure you control, a server-side `pre-receive` hook that rejects pushes whose topology violates the rule. Note the local config is advisory — anyone can override it with a flag — so if the rule genuinely matters, the enforcement has to sit where the objects arrive. ## The strongest signal in an answer Say out loud that **consistency beats the specific choice**. A repository where half the features are squashed, some are fast-forwarded and some carry merge commits gives you the drawbacks of all three: `--first-parent` is incomplete, bisect granularity is unpredictable, and nobody can tell whether a branch was integrated. Also say what would make you revisit the decision — for example, if incident response repeatedly needs whole-feature reverts, or if the log has become unreadable — because a topology decision is reversible going forward even though it cannot be applied retroactively.