Merge Methods, Merge Trains, Mergeability Checks, Conflict Resolution, and Integration Strategies: Configuration, Design Choices, and Tradeoffs

1. Start with the invariant you want to preserve

Do not begin with “we like clean history.” Begin with operational invariants: must every reviewed source commit remain identifiable? Must the target be strictly linear? Must CI test the exact candidate bytes that will land? Must releases be traceable to a merge commit? How expensive is rerunning pipelines?

2. Merge-method tradeoffs

3. Squash is an orthogonal policy dimension

GitLab can set squash to never, always, default on, or default off. Under merge-commit mode, squashing can create a squash commit and then a merge commit. Under fast-forward mode, the target can advance to the squash commit. Therefore “we squash” does not fully describe the target graph.

Long-running source branches are a poor squash candidate because the target receives a new commit SHA representing prior source work while the source branch still contains the original commits. Continued development can produce confusing divergence unless the branch is rebased or synchronized.

4. CI validity versus friction and compute

5. Merge trains: throughput versus latency

Merge trains improve confidence when many MRs target the same branch. Their value rises with concurrency: each car is tested in the context of earlier train cars. The cost is extra pipelines, queue management, and possible restarts when earlier entries fail or leave the train.

A small team merging twice a day may gain little from a train. A monorepo integrating dozens of ready changes per hour may gain substantial reliability despite compute cost. Measure queue time, failed-car rate, pipeline duration, and wasted compute before deciding.

6. Web editor versus local Git

7. Automatic source-branch cleanup versus forensic convenience

Automatic deletion is ideal for short-lived feature branches after successful merge because the target/MR preserve durable history. Retain a branch temporarily when an incident, release verification, multi-step migration, or dependent branch still needs the named ref. Either way, record the source tip before deletion and prove merged commits remain reachable.

SOURCE_SHA="$(git rev-parse origin/ch09-feature)"
TARGET_SHA="$(git rev-parse origin/main)"
printf 'source=%s
target=%s
' "$SOURCE_SHA" "$TARGET_SHA"

# Before deleting the source pointer, prove reachability from the target.
if git merge-base --is-ancestor "$SOURCE_SHA" "$TARGET_SHA"; then
  echo "source tip is reachable from target"
else
  echo "source tip is NOT an ancestor; inspect merge/squash semantics before cleanup"
fi

8. Worked production decision

Scenario: a regulated service needs auditable MR boundaries, retains individual developer commits, averages eight merges/day, and cannot justify paid merge trains. The team also requires the source to be up-to-date before integration.

Knowledge check

Summary

Integration policy should follow explicit invariants: history shape, candidate validity, traceability, throughput, and recovery. Merge trains are a scaling/reliability tool, not a universal default; squash is not a complete merge strategy by itself; and branch cleanup is safe only after evidence and reachability are proven.

Official references

• GitLab Docs — Merge methods
• GitLab Docs — Squash and merge
• GitLab Docs — Merge conflicts
• GitLab Docs — Merge trains
• GitLab Docs — Merged results pipelines
• GitLab Docs — Merge request pipelines
• GitLab Docs — Auto-merge
• GitLab Docs — Merge requests API
• GitLab Docs — Projects API
• GitLab Docs — Project settings
• GitLab Docs — Merge requests
• GitLab Docs — Default branch
• GitLab Docs — Merge trains API
• GitLab Docs — REST API pagination
• GitLab Docs — glab API