Collaboration and conflict — concurrent edits and the merge boundary

Git’s collaboration model is built on top of snapshots. Two engineers working from the same commit can each produce a new commit; when the repository is asked to combine them, Git looks at the two commits, walks back to the common ancestor, and performs a three-way merge. When the two sides changed different parts of the same file, the merge is mechanical. When they changed the same lines, the merge is a question only a human can answer, and Git stops and asks.

The three-way merge

When you merge two commits, Git identifies their merge base — the most recent commit that is an ancestor of both. It then compares the state of each side against the base, line by line, and applies the non-conflicting changes from both sides into the result. This is the same algorithm that git merge, git rebase, and git cherry-pick all use, because the algorithm is just the question “what did each side change, relative to the common ancestor?”.

flowchart TB
    A["Base\ncommit B"] --> C["Branch A\ncommit A"]
    A --> D["Branch B\ncommit B2"]
    C --> E["Merge commit"]
    D --> E
    E --> F["Three-way merge\nA vs B vs base"]

The merge base is found by walking the parent pointers of both commits backwards until a common ancestor is reached. For two branches that diverged from a single commit, the base is that commit. For more complex histories (an octopus merge, a recurring branch), Git selects the “best” common ancestor heuristically.

# Find the merge base of two branches
git merge-base feature-a feature-b

# Show the merge result without committing
git merge-tree --write-tree feature-a feature-b

What Git can resolve

A merge is automatic when the two sides changed different hunks of the same file, or when only one side changed a file at all. The rule is local to each hunk: if only one side touched the lines, the change is unambiguous; if both sides touched different lines, the changes can be combined. The pattern Git is implementing is “merge if the intersection of edited line ranges is empty”.

Git can also resolve clean rename-and-modify combinations: if main renamed policy.tf to iam.tf and feature edited policy.tf, Git detects the rename via similarity scoring and applies the edit to the new path. This is the same lexical analysis that powers git log --follow.

What Git cannot resolve

A merge conflict is what Git produces when the two sides edited the same lines, deleted a file that the other side modified, or one side modified a file while the other deleted it. In every case, the conflict is a marker in the working tree that says “this hunk has two competing edits and I cannot pick one for you”.

sequenceDiagram
    participant M as Merging side
    participant G as Git
    participant H as Human
    M->>G: git merge feature
    G->>G: find merge base
    G->>G: compare hunks
    alt hunk ranges disjoint
        G-->>M: merge commit
    else hunk ranges overlap
        G->>H: write conflict markers
        H->>G: edit and git add
        G-->>M: merge commit
    end

The conflict markers in the file are a literal text-based reproduction of both sides’ edits, with <<<<<<<, =======, and >>>>>>> fences. The engineer reads the conflict, decides what the combined file should contain, removes the markers, and stages the result. The decision is deliberately not made by the system: a textual conflict is a signal that the human needs to make a semantic decision.

# See the files Git marked as conflicted
git diff --name-only --diff-filter=U

# Inspect the conflict hunks for a file
git diff --check "$PATH"

Merge versus rebase

Two ways to integrate a branch into main are merge and rebase. A merge produces a merge commit; the branch’s history is preserved. A rebase replays the branch’s commits on top of main, producing a linear history with no merge commit. The trade-off is not technical correctness — both produce the same working tree — but history shape: merges preserve the topology of “this work happened in parallel”; rebase erases it. Infrastructure repositories usually prefer merge, because the preservation of the parallel history is itself audit information.

Production discipline

Two rules apply universally in infrastructure repositories:

1. Branch protection is non-negotiable. Every change to main arrives through a pull request with at least one reviewer and a green CI run. The merge boundary is the production control point; removing it is removing the gate.
2. Conflict resolution is a pair-review. When a merge conflict is non-trivial, the resolution should be visible to (and ideally authored by) the original author of one of the sides. The conflict encodes a semantic question about the system; the engineer who understands the system is the one who can answer it.

Cross-course references

• Linux for Production Sysadmins - Part XXVIII (ChangeMgmt) covers the dual-control principle that mirrors the pair-review of merge conflicts.
• Ansible for Production Sysadmins - Part XXXVII (RepoArch) discusses when to merge versus rebase in Ansible role repositories.
• Terraform for Production Sysadmins - Part XIX (PR) discusses Terraform plan files as a merge artefact, and how a merge conflict in a plan file is a different kind of conflict than a merge conflict in HCL.

Quiz