What a fast forward merge does in Git

A fast forward merge is Git being efficient and a little smug. If you created a feature branch from main and main did not get any new commits while you worked, merging that feature back can mean no new merge commit ever appears. Git simply advances the main pointer to the tip of your feature branch. The history stays linear and neat which pleases some humans and alarms the rest.

How this happens in practice

Picture this git graph scenario. You branch off main then add commits only on the feature branch. Since main did not change Git can resolve the merge by moving the main reference forward. No merge commit is created and the timeline looks like someone swept up after themselves.

git checkout main
git merge feature-branch

When Git will not fast forward

If main gained commits after you branched then a true merge is required. Git will either create a merge commit or prompt you to resolve conflicts first depending on the situation and your merge options. That merge commit is the visible junction where histories come together.

When you might want to avoid a fast forward merge

Sometimes you want a visible record that a set of commits belonged to a named branch. This helps when you need to revert a whole feature or when your team likes having a tidy box around work. To force a merge commit even when a fast forward would be possible use this command

git merge --no-ff feature-branch

How to check what actually happened

Want proof instead of feelings Use the following git log view to inspect whether merges were fast forwarded or produced merge commits

git log --graph --oneline

Graph view gives you the visual confirmation that a thousand words could not match and it also shows which merges left a fingerprint in the history.

Practical recommendations and git tips

• Prefer fast forward merges for tiny fixes and trivial updates to keep history linear and readable.
• Use git merge --no-ff for larger features when grouping commits under a merge commit helps future maintenance and audits.
• If your team relies on release bisecting or clear audit trails favor merge commits so you do not surprise your future self.
• Rebase is another tool to keep history linear but it rewrites history so use it with care on shared branches.

In short Git will fast forward when it can and it will not when branching histories diverge. Decide if you want that invisible tidy history or a visible merge commit that tells the story of a feature. Either choice is valid unless your CI pipeline has opinions and then you do what CI says.