Merge Strategies and History Shape

Merge Strategies and History Shape

Module: Module 4: Merging, Rebasing, and Conflict Mastery

A merge is not just a way to combine files; it also records a history shape. Fast-forward, no-fast-forward, squash, and octopus merges each communicate something different.

A fast-forward merge moves a branch ref forward because no divergent history exists. A no-fast-forward merge creates a merge commit even when fast-forward is possible, preserving the branch as a visible unit of work. A squash merge creates one new commit with the combined changes but does not preserve the branch commits as parents.

There is no universal best merge style. Libraries, product apps, monorepos, and release branches may prefer different shapes. The important decision is whether the team values individual commit history, a linear main branch, or explicit merge records.

Command Walkthrough

git merge feature-branch
git merge --no-ff feature-branch
git merge --squash feature-branch
git log --oneline --graph --first-parent main
git show --cc <merge-commit>

commit d4e5f6a7b8c9
Author: Alex Engineer <[email protected]>

    Add focused change

 app.conf | 2 +-

Hands-on Lab

Create three short feature branches and merge one with fast-forward, one with --no-ff, and one with --squash. Draw the resulting graph and explain what information each style keeps or loses.

What to Watch For

• Squash merge can make later cherry-picks and revert reasoning different because original commits are not parents of main.
• No-fast-forward merge preserves context but can make history visually noisy in high-volume repositories.
• Fast-forward history is simple, but it can hide where a feature branch started and ended.

Completion Check

You should be able to explain what each command changed, inspect the resulting history, and describe how you would undo or recover from the operation before using it in a shared repository.