AI Coding Agents
Git Workflows
Merge conflict resolution with coding agents
September 22, 2026 - 2 minute read
Coding agent merge conflict resolution can save time when two branches edit the same code, but a clean Git index proves only that the conflict markers are gone. The final file still has to preserve the intent of both changes. A useful agent workflow begins with a fixed base, explains each resolution, and runs checks against the combined behavior.
Git records conflicts when it cannot combine changes automatically. The official git merge documentation describes the index entries and working-tree markers available during resolution. Those artifacts identify overlapping text. They do not explain which behavior the team wants to keep.
Reproduce the conflict from known commits
Record the target branch, source branch, and exact commit identifiers before asking an agent to resolve anything. Fetch the required refs, start from a clean worktree, and reproduce the merge or rebase with the repository’s normal command. A moving branch can produce a different conflict minutes later, so pinning the inputs keeps the task reviewable.
Give the agent the pull request description, acceptance criteria, recent changes to the affected files, and relevant ownership rules. Generated files need their source identified. Lockfiles need the package manager and approved regeneration command. Database schemas and API definitions need compatibility requirements, not just syntax checks.
Repeated conflicts may benefit from Git’s recorded resolution mechanism, which stores a manual resolution and can reuse it when the same conflict appears again. Treat the reused result as a starting point. Changes around the conflict can make an old resolution incomplete even when Git applies it cleanly.
Resolve behavior before syntax
Read both sides and the common ancestor before editing. The base shows what each branch changed, while tests and call sites reveal the contract those edits were meant to preserve. For a renamed function plus a new validation rule, the correct result may combine the new name with the new check. Choosing one side wholesale would silently discard valid work.
Keep the resolution narrow. Avoid unrelated formatting, dependency updates, or refactors that make the merged behavior harder to inspect. Run formatters only where repository instructions require them. If the branches made incompatible product decisions, stop and report the decision instead of guessing.
Factory’s local code review can compare the resolved branch with its base or review the uncommitted resolution. Custom instructions can focus the pass on dropped conditions, duplicated side effects, changed error handling, or performance regressions.
Validate the combined change
Search for conflict markers, inspect the staged diff, and run the smallest tests that exercise both branches’ intent. Then run the repository’s required broader checks. A merge involving authentication should cover allowed and denied paths. A lockfile conflict should include a fresh install or integrity check. A generated client should be rebuilt from its schema.
The pull request should name the conflicting commits, affected files, resolution decisions, and commands run. Reviewers need to see where the agent combined behavior, where it selected one side, and where a human decision remains open. That evidence turns an opaque conflict cleanup into a normal code review.
