Git Integration Strategy Decision Guide: Merge Commit vs. Fast-Forward vs. Rebase vs. Squash

The Decision: What Should Mainline History Preserve?

You have a reviewed feature branch ready to land in a shared mainline. The technical decision is not simply "merge it" — it is whether the mainline must preserve the branch's topology and individual commits, or only the net change. Every strategy below produces a different commit graph, and that graph determines how you bisect regressions, revert changes, and cherry-pick into release branches.

Constraints That Narrow the Choice

Before selecting a strategy, answer three questions. First, is the feature branch already shared? Rebasing rewrites commit IDs, which breaks clones that have already pulled those commits. Second, does your team require an explicit integration record? A merge commit records that a branch existed and was integrated; a fast-forward or squash leaves no such marker. Third, do downstream processes need individual commits? Release branches that cherry-pick or partially revert specific steps require per-commit granularity that a squash destroys.

Hosted platforms add a fourth constraint. GitHub, GitLab, and similar services apply their own merge strategy in the web UI, which may differ from your local Git defaults. Configure the server-side or repository-level settings to match the strategy your team actually uses, or the resulting history will diverge from what you validated locally.

Supported Options at a Glance

Strategy	History Shape	Integration Record	Shared-Branch Safety	Per-Commit Traceability
git merge --no-ff	Non-linear; merge commit with two parents	Explicit merge commit	Safe	High
git merge --ff-only	Linear; main pointer moves forward	None	Safe if main has not advanced	High
git rebase main then FF	Linear; commits rewritten onto new base	None	Unsafe if already pushed	High, but commit IDs change
git merge --squash	Linear; single new commit with one parent	None	Safe	Low; sub-commit messages dropped

Trade-offs in Practice

Merge Commit (--no-ff)

This is the safest default when you need to preserve branch topology. The merge commit has two parents: the previous mainline tip and the feature branch tip. Reverting the entire change is a single command, git revert -m 1 <merge-commit>, because the first parent is the mainline. The cost is a noisier graph with explicit merge nodes, which some teams find harder to read.

Fast-Forward Only (--ff-only)

When the feature branch is strictly ahead of main and no integration record is required, git merge --ff-only simply moves the main pointer forward. It never creates a merge commit. Critically, it exits with a non-zero status if main has advanced, which prevents accidental loss of remote work and makes the precondition explicit in scripts. Do not let CI silently fall back to another strategy when this fails.

Rebase Then Fast-Forward

Rebasing replays your commits onto the current tip of main, producing a linear history without a merge commit. This yields a clean bisect path. However, rebase rewrites commit IDs. If collaborators have already pulled the original branch, they must recover with a forced update or re-clone. Reserve this for local or unshared branches, or coordinate a forced push with the team.

Squash Merge

A squash collapses the entire branch into one new commit with a single parent. It simplifies history and makes reverts trivial. The trade-off is loss: per-commit messages and authorship granularity disappear unless the pull-request description preserves them. Squash also complicates cherry-picks or partial reverts into release branches, because those operations reference only the squashed commit.

Concrete Implementation and Validation

Run all commands from a local clone with push access to the shared remote. Replace <feature-branch> with your branch name and origin with your remote name.

# Ensure main is current
git checkout main
git pull origin main

# Strategy A: merge commit
git merge --no-ff <feature-branch>

# Strategy B: fast-forward only
git merge --ff-only <feature-branch>

# Strategy C: rebase then fast-forward (unshared branches only)
git checkout <feature-branch>
git rebase main
git checkout main
git merge --ff-only <feature-branch>

# Strategy D: squash
git merge --squash <feature-branch>
git commit -m "Integrate <feature-branch>: <short-summary>"

After integration, validate mechanically rather than by eye. Inspect the topology with git log --graph --oneline -10. A merge commit shows two converging lines; the other strategies show a single line. Confirm the resulting tree matches the reviewed branch with git diff <feature-branch> HEAD; an empty diff proves the tree is identical to what reviewers approved. For a rebase, use git range-diff <old-base>..<feature-branch> <new-base>..HEAD to compare the original and rewritten commit ranges.

If your pipeline must run on the exact resulting commit, trigger CI after the merge, rebase, or squash completes — not only on the pre-merge feature tip. For merge commits, verify the second parent with git show --no-patch --format='%P' HEAD; the output should list two commit IDs.

Limitations and Recovery

None of these strategies are universally correct. A squash merge cannot be undone commit-by-commit; revert the single squashed commit instead. A rebased linear history requires reverting individual commits rather than a merge commit. If git merge --ff-only fails because main advanced, update main and re-evaluate — do not force a fallback strategy without checking what changed.

To build confidence, create a scratch clone and run each strategy in a separate clone. Compare the git log --graph output and the git diff results. This takes minutes and prevents surprises in the shared repository.