Why Use --no-ff When Merging in Git? Understanding Its Impact on History

Understanding the --no-ff Option in Git Merges

Many Git workflow guides recommend adding the --no-ff flag when merging a feature branch into the main branch. The flag disables fast‑forward merges, forcing Git to create a new merge commit even when a fast‑forward would be possible.

When Git can reach the target branch by simply moving the branch pointer forward, it performs a fast‑forward merge. For example:

A---B---C  feature
         /
D---E---F  master

Running the usual merge commands:

$ git checkout master
$ git merge feature

results in the master pointer moving directly to commit C, so both master and feature point to the same commit:

A---B---C  feature
         /          master
D---E---F

If the same merge is performed with git merge --no-ff feature, Git creates an additional merge commit:

A---B---C  feature
         /          \
D---E---F-----------G  master

The --no-ff flag forces Git to generate commit G, preserving a distinct merge point in the history.

Although the resulting codebase is identical, the presence of a merge commit keeps the history of the feature branch separate from the main line. This is valuable because the master branch typically holds stable code with few commits, while a feature branch may contain many small, incremental commits. A fast‑forward merge would intermix those feature commits into master, cluttering its history.

If you do not care about a tidy history, the --no-ff option may seem unnecessary. However, when you need to revert the main branch to a previous state, having an explicit merge commit makes it clear which commits belong to the feature and prevents accidental loss of history. For instance, reverting after a problematic merge would move the pointer back to commit B instead of F, because the feature’s commits are encapsulated in the merge commit.