Separate worktrees stop two agents from overwriting each other's uncommitted files. They do not decide which behavior wins when both branches change the same code. Treat the conflict as a product and code decision, not a marker-removal exercise.
Stop new edits and name the integrator
Pause the two code-changing sessions at committed, reviewable states. Record each branch, worktree, issue, and intended outcome. Pick one person or agent to prepare the integration branch, with a person approving the result. If both agents continue writing while the conflict is resolved, the decision can become stale before it is tested. Canopy's Agent Workspace and Git surfaces help trace sessions to branches and diffs according to the current-main app documentation; check the installed release for exact controls.
Inspect before starting a merge
In a clean integration checkout, run git status --short and inspect both branch diffs against their common base. Read each task brief or PR and identify the contract each branch expected. In a settings example, one agent may rename a field while another adds validation to the old field name. Git may produce a clean text merge while the app breaks at runtime, so look for semantic overlap as well as lines that Git marks conflicting. Commit or otherwise preserve unrelated local work before merging; Git warns that aborting a merge may not reconstruct pre-existing uncommitted changes in every case.
Resolve the behavior, then the text
Merge one reviewed branch into the integration branch and then attempt the second. If Git stops, git status lists unmerged paths. Read the conflict markers and surrounding call sites; compare both branches and the base. Choose an outcome that satisfies both accepted requirements, or send the decision back to the owners if the requirements cannot both hold. Do not routinely select ‘ours’ or ‘theirs’ for a whole file: that can silently discard valid work. Edit the final code, stage only resolved paths, and inspect the staged diff before completing the merge.
Test the combination
Run checks for both original tasks and an integration path crossing them. For the renamed field example, test saving a valid value, rejected input, and the API payload. Start the relevant local services and inspect the running behavior. A branch can pass its own tests yet fail when combined with another branch. Review the integration diff for unrelated formatting, missing code, conflict markers, and schema or API drift before presenting the PR.
Leave a decision record and reduce the next collision
In the integration PR, record the two branches, conflicting contract, chosen behavior, commands run, and any remaining follow-up. Update both issue owners so neither restarts from the old assumption. For the next parallel task split, agree on shared interfaces early and assign one owner to files such as routes, schemas, or lockfiles. Separate worktrees protect working directories; task boundaries protect the integration path.
Copyable resources
Conflict triage commands
Run in a clean integration checkout; replace branch names and inspect before completing a merge.
git status --short
git branch --show-current
git diff --stat main...agent/first
git diff --stat main...agent/second
# Read each branch's task brief and detailed diff before merging.
git merge agent/first
git merge agent/second
# If stopped on conflicts:
git status
git diff
# Resolve the required behavior in each file, then stage only reviewed paths.
git add path/to/resolved-file
git diff --cached --check
git diff --cached
git merge --continue
# Run both task checks and an integration check before PR review.
# If the merge decision is not understood, stop; git merge --abort may help only after checking local changes.Frequently asked questions
Why did worktrees still produce a merge conflict?
Worktrees isolate working files while agents edit. Branches can still change the same lines or introduce incompatible assumptions when their histories are combined.
Can I ask an agent to take one side of every conflict?
Only after checking that the other side has no required behavior. Review both tasks and the final diff; a whole-file choice can discard valid code without a visible error.