Git Merge Strategies — DevOps Workflow

When integrating feature branches into main or releasing, merge strategy choice affects history readability, CI traceability, and rollback.

Quick comparison

Strategy	Command / config	Result	Best for
Fast-forward (FF)	git merge --ff-only	Linear history, no merge commit	Short-lived feature branches, clean rebase
No fast-forward	git merge --no-ff	Explicit merge commit, preserves branch identity	Releases, long-running features, audit trails
Squash	git merge --squash	One commit from branch onto target	Ephemeral PR branches, clean main
Ours / Theirs (resolution)	git merge -X ours / -X theirs	Favor one side during conflict	Hotfix overrides, vendor sync

Practical CI usage

# Enforce explicit merge commits for release branches (audit trail)
git merge --no-ff release/v2.4.0 -m "merge(release): v2.4.0 deploy gate"

# Squash a feature PR into main to keep history linear
git checkout main
git merge --squash feature/auth-refactor
git commit -m "feat(auth): refactor token flow" --no-edit

# Resolve recurring config drift quickly with ours/theirs
git merge -X ours upstream/config --no-edit

Conflict automation (DevOps)

# Pre-set merge strategy preference globally for CI
git config --global merge.conflictstyle zdiff3
# Favor ours during vendor updates
git merge -s recursive -X ours vendor/update

Key benefit: merge strategy controls traceability. Use --no-ff for deploy/release gates (reversible), --squash for feature PRs (clean), -X ours/theirs for automated vendor/config sync.