In Git, how do --no-ff, --ff-only and merge.ff change what git merge produces?

## The decision they all touch When you run `git merge`, Git first asks whether the merge can fast-forward — whether your current commit is already an ancestor of the commit being merged. If it can, the default is to move the branch pointer and record nothing. `--no-ff`, `--ff-only` and `merge.ff` all sit on exactly that decision. If the histories have genuinely diverged, `--no-ff` is a no-op (a merge commit was required anyway) and `--ff-only` simply refuses. ## --no-ff `git merge --no-ff <branch>` tells Git to create a merge commit even though a fast-forward was available. The resulting commit has two parents: the first is where your branch was, the second is the tip of the merged branch. Its tree is identical to the merged branch's tree, because your side contributed nothing — so the merge commit adds no content, only structure. Why pay for that empty-looking commit? - **Grouping.** `git log --graph` shows the branch forking and rejoining, so a reader can see which commits shipped together. - **Revertability.** `git revert -m 1 <merge>` backs out the whole feature in one commit, because the merge commit is the single point where it entered the branch. - **First-parent history.** `git log --first-parent` then lists one entry per merged branch, giving a coarse, readable changelog of the branch. The cost is a busier graph and a commit that shows no diff against its second parent, which confuses readers who expect every commit to contain changes. ## --ff-only `git merge --ff-only <branch>` inverts the guarantee: perform the merge only if it is a fast-forward, otherwise do nothing at all and exit non-zero with `fatal: Not possible to fast-forward, aborting.` Nothing is staged, no conflict state is entered, and the branch ref is unchanged. This is a *guard*, not a rewrite. A common misconception is that `--ff-only` linearises history; it does not. It refuses, and it is then your decision to rebase your work, or to merge deliberately with an explicit merge commit. It is the flag to reach for when you want a branch to stay a straight line and you want the failure to be loud instead of silently accumulating merge commits. ## merge.ff `merge.ff` is the config key holding the default: - `true` — fast-forward when possible. This is Git's default. - `false` — never fast-forward; always create a merge commit. Same effect as passing `--no-ff` every time. - `only` — refuse anything that is not a fast-forward. Same effect as `--ff-only`. It lives anywhere config lives, so it can be set per repository (`git config merge.ff false`) or globally. A flag on the command line always beats the config, so `git merge --ff <branch>` still fast-forwards in a repository configured with `merge.ff = false`. A related key, `pull.ff`, controls the same decision for the merge performed by `git pull` and takes precedence over `merge.ff` in that case. Keep the two straight: configuring one does not silently configure the other's precedence. ## What they do not change None of these options changes the merge *result* in terms of file content. In the fast-forwardable case the resulting tree is the merged branch's tree either way; `--no-ff` only adds a commit node above it. They also do not touch the commits on the feature branch — nothing is rewritten, squashed, or reordered. If you want the incoming commits collapsed into one, that is `git merge --squash`, a different mechanism with a different topology. ## Choosing between them A team that values a linear, bisect-friendly log will set `merge.ff = only` (or rely on rebasing) so that merges either slide forward or fail loudly. A team that values seeing feature boundaries will set `merge.ff = false` so every integration is a visible, revertible bubble. The important part in an interview is not which one you prefer but that you can state what each produces and what that costs: consistency across the repository matters more than the choice itself, because a history that mixes both conventions is the one nobody can read.