Exploring Different Git Merge Strategies and Options

Fast-forward merge is used when the target branch hasn’t diverged, resulting in a linear history by moving the branch pointer forward without a merge commit, but it loses feature branch context. 2. No-fast-forward merge (--no-ff) forces a merge commit even when fast-forwarding is possible, preserving the feature branch’s identity and enabling easier reverts, at the cost of a slightly more complex history. 3. Squash merge (--squash) combines all changes from a feature branch into a single commit on the target branch, ideal for cleaning up messy histories, though it doesn’t create a true merge and prevents safe branch deletion via --merged. 4. Recursive merge strategy is Git’s default for diverged branches, using a common ancestor to resolve changes and create a merge commit, with advanced options like -X patience for better diff handling in noisy files. 5. Ours merge strategy (-s ours) keeps the current branch’s content entirely, discarding changes from the incoming branch, useful for marking integration without applying changes. 6. Octopus merge allows merging multiple branches at once, but only proceeds if the merge is conflict-free, falling back to recursive otherwise, and is rarely used in practice. 7. Key merge options include -X ours/-X theirs for automatic conflict resolution, --no-commit to review changes before committing, --abort to cancel a failed merge, and --rerere to reuse previous conflict resolutions, with strategy choice depending on team goals for history clarity, traceability, and workflow efficiency.

When working with Git, merging is a fundamental part of collaboration. It allows teams to integrate changes from one branch into another—typically bringing feature branches into main or develop. However, not all merges are the same. Git offers several merge strategies and options, each suited to different workflows and goals. Understanding these can help you maintain a clean history, avoid conflicts, and streamline team collaboration.

Here’s a breakdown of the most common Git merge strategies and key options you should know.

1. Fast-Forward Merge (Default Behavior)

A fast-forward merge occurs when the target branch (e.g., main) hasn’t diverged from the source branch (e.g., feature). Instead of creating a new merge commit, Git simply moves the pointer of the target branch forward to match the source.

When it happens:

• The target branch has no new commits since the feature branch was created.
• Linear history is preserved.

git checkout main
git merge feature  # Results in a fast-forward if possible

Pros:

• Clean, linear history.
• No extra merge commit.

Cons:

• Loses context of the feature branch (since it’s absorbed).
• Harder to revert a feature as a whole.

? Use --no-ff to avoid fast-forwarding and preserve branch context.

2. No-Fast-Forward Merge (--no-ff)

This strategy forces Git to create a merge commit even if a fast-forward is possible.

git merge --no-ff feature

Why use it?

• Preserves the fact that a feature was developed in a separate branch.
• Makes it easier to visually track and revert entire features.

Result:

• A merge commit is always created.
• Slightly more cluttered history, but better traceability.

This is popular in workflows like Git Flow, where maintaining feature boundaries matters.

3. Squash Merge (--squash)

Instead of merging the entire branch, --squash combines all changes from the feature branch into a single commit on the target branch.

git merge --squash feature
git commit -m "Add user authentication feature"

Use cases:

• Cleaning up a messy feature branch with many small or WIP commits.
• Integrating experimental branches without polluting history.

Important:

• No actual merge commit is created.
• The feature branch is not marked as merged (so you can’t safely delete it via --merged).

Best for teams that value a clean, concise project history over full traceability.

4. Recursive Merge Strategy (Default for Two Heads)

When both branches have diverged, Git uses the recursive strategy by default (for two heads). It finds a common ancestor, applies changes from both branches, and creates a merge commit.

git merge feature  # Uses 'recursive' under the hood

This strategy handles most typical merge scenarios and is smart about resolving overlapping changes.

Advanced option:

• git merge -s recursive -X patience — uses a more careful diff algorithm, helpful in large files or noisy diffs.

Useful when dealing with legacy code where whitespace or reordering causes noise.

5. Ours Merge Strategy (-s ours)

The ours strategy keeps the current branch’s version of files and ignores changes from the incoming branch.

git merge -s ours feature

Use case:

• You want to mark a branch as merged but keep your current code.
• Useful when temporarily merging a branch without applying its changes (e.g., for testing or CI purposes).

Note: This doesn’t mean “my changes win”—it means “discard all changes from the other branch entirely.”

6. Octopus Merge (Multiple Branches)

Git can merge more than two branches at once using the octopus strategy (default for >2 heads).

git merge feature-a feature-b feature-c

Limitation:

• Only proceeds if the merge is trivial (no conflicts).
• Falls back to recursive if conflicts exist.

Rarely used in practice but handy for integrating multiple independent features quickly.

7. Merge Options to Handle Conflicts and History

Beyond strategies, Git provides merge options to fine-tune behavior:

• -X ours / -X theirs: During a conflict, automatically favor changes from one side.

  git merge -X ours feature  # In case of conflict, keep current branch's version

• --no-commit: Perform the merge but don’t auto-commit. Lets you review or tweak changes.

  git merge --no-commit feature
  git status  # Review changes
  git commit  # Manually commit

• --abort: If a merge goes wrong, cancel it.

  git merge --abort

• --rerere: Reuse recorded resolution. Helps if you’re repeatedly resolving the same conflicts.

---

Choosing the Right Strategy

Goal	Recommended Strategy
Keep history clean and linear	Fast-forward (or squash)
Preserve feature context	--no-ff
Clean up messy commits	--squash
Resolve complex conflicts	-X patience or manual merge
Integrate without changing code	-s ours

---

Ultimately, the best merge strategy depends on your team’s workflow, review practices, and how much history clarity matters. Many teams standardize on --no-ff or squash merges via pull requests to balance cleanliness and traceability.

Knowing your options gives you control—not just over code, but over collaboration.

The above is the detailed content of Exploring Different Git Merge Strategies and Options. For more information, please follow other related articles on the PHP Chinese website!