Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
When two coding agents change overlapping work, do not choose “ours” or “theirs” automatically. First preserve the repository state, inspect the base, current, and incoming versions, then edit the file into one intentional result. Stage that result, run the project’s checks, and complete or abort the merge deliberately. If both agents implemented the same behavior without a textual conflict, compare their diffs against the common starting point and consolidate the code instead of keeping two competing implementations.
What a conflict means
A Git merge conflict is a warning that Git could not determine the correct combined result. The usual case is that both branches changed the same line or nearby lines. An edit/delete conflict occurs when one side edits a file while the other deletes it. Renames, binary files, and file-versus-directory changes can also require a decision that marker text alone cannot express.
The conflict is not evidence that one agent was right and the other was wrong. Each side may contain part of the intended feature, a bug fix, a test update, or a necessary interface change. Treat the conflict as an inspection point: identify what each task was supposed to accomplish, preserve compatible work, and remove only code that is genuinely redundant or incorrect.
During an unresolved merge, Git keeps three versions in the index:
#1 Best Overall
- Stage 1: the common base before either side’s change.
- Stage 2: your current checkout, commonly called “ours.”
- Stage 3: the branch being merged, commonly called “theirs.”
Understanding those stages prevents a common mistake: assuming “ours” means the newest or most correct implementation. It only identifies the side associated with the current branch during this merge.
Freeze the situation before editing
Start by recording exactly what Git considers unresolved. Do not run cleanup commands, reset the branch, or delete files until you know whether the merge is local and recoverable.
- Run
git status. Look for a message that a merge is in progress and note every path under “Unmerged paths.” - List only unresolved paths with
git diff --name-only --diff-filter=U. - Save or stash unrelated uncommitted work if your team’s workflow permits it. Do not stash away the conflict itself without understanding what will be restored.
- Read the task description, issue, tests, and interface contract for each agent. The correct resolution is a behavioral decision, not merely a syntactic one.
Work on one conflicted path at a time. If an agent generated files, check whether those files are source-controlled outputs or artifacts that should be regenerated after the source conflict is resolved.
Recommended Free Tools
Resolve a normal textual conflict from all three versions
Read the markers and surrounding code
Open the file and locate blocks such as:
<<<<<<< HEAD
current branch content
=======
incoming branch content
>>>>>>> feature-branchThe labels identify sides, not priority. Read more than the marked lines: function signatures, imports, error handling, comments, callers, and tests often reveal which behavior must survive.
Inspect the base, current, and incoming files
For a conflicted path, replace path/to/file with the actual path and inspect each index stage:
git show :1:path/to/file
git show :2:path/to/file
git show :3:path/to/fileYou can also ask Git to show how the working result differs from each side:
git diff --base -- path/to/file
git diff --ours -- path/to/file
git diff --theirs -- path/to/fileThe base answers “what did both agents start from?” The two side versions answer “what did each agent intend to change?” Compare behavior, not just line order. For example, one agent may add validation while the other changes the return type; the combined implementation may need both, plus updated callers.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteRank #2
- Used Book in Good Condition
Edit the file into the intended result
Remove every conflict marker and write one coherent implementation. Preserve compatible changes, reconcile changed names and data shapes, and update comments so they describe the resulting behavior. If both sides add tests for different cases, keep both when they cover distinct requirements. If they assert incompatible contracts, resolve the contract first and then make the tests agree with it.
Do not leave a marker hidden in a comment or string. Search the resolved file and, preferably, the whole tree for <<<<<<<, =======, and >>>>>>> before staging.
Review, stage, and continue
- Inspect the working-tree result with
git diff -- path/to/file. - Where your merge strategy supports it, inspect the automatic merge result with
git diff AUTO_MERGE. This can expose changes that are easy to miss while reading a large file. - Run the formatter, type checker, unit tests, or other project checks relevant to the changed code.
- Mark the path resolved with
git add path/to/file. For a deliberately deleted file, usegit rm path/to/file. - Run
git statusagain. Confirm that no unmerged paths remain. - Finish with
git merge --continuewhen Git requests continuation. If the merge process does not provide that command, complete it withgit commitand retain a useful merge message.
Staging does not mean Git has verified the behavior. It only records that you have chosen the file’s resolved contents. Tests and a final diff review are still required.
Handle conflicts that markers cannot explain
Edit/delete conflicts
If one agent modified a file and the other deleted it, decide whether the feature still needs that file. Keep and integrate the edit when the file remains part of the design; delete it when the deletion is intentional, then update imports, build configuration, documentation, and tests that referenced it. Resolve by staging the chosen state with git add or git rm, not by leaving the path untracked.
Renames and path changes
When one side renames a file and the other edits its old path, inspect both the old and new paths and search the repository for references. A correct result may require keeping the rename while carrying the edit into the new path, followed by updates to imports, scripts, and documentation. Git’s similarity detection is helpful but does not understand the project’s intended module boundaries.
Binary files
Git cannot merge binary content line by line. Decide which binary is authoritative or regenerate it from source. Do not attempt to resolve a binary conflict by editing textual markers. If the binary is generated, resolve the source files first and run the documented generation step.
File-versus-directory conflicts
One side may create a file where the other creates a directory, or vice versa. Determine the desired path layout, move or remove files deliberately, then stage every affected path. Check case sensitivity if agents worked on different operating systems; a rename that differs only by capitalization can behave differently across filesystems.
Rank #3
Git’s lower-level merge information is useful for these cases because the conflict is about repository structure, not just a pair of text blocks.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Do not use automatic side selection as a generic repair
Options such as -Xours, -Xtheirs, and the ours merge strategy have specific meanings. They can select one side for conflicting hunks or discard the other side’s tree. They are appropriate only when you have established that one side must entirely win for the stated reason, such as intentionally replacing an obsolete branch. They are unsafe as a time-saving response to an unfamiliar conflict because they can silently remove an agent’s validation, migration, tests, or security fix.
If only one small hunk is known to be obsolete, resolve that hunk manually and preserve the rest of the branch. A deliberate, documented decision is safer than a broad option whose effect is easy to overlook.
Find and remove duplicated implementations
Not every duplicate edit creates a Git conflict. Two agents can add separate functions, handlers, migrations, or tests that compile cleanly but implement the same behavior. This is a semantic collision: Git sees different lines, while the product now has two competing sources of truth.
Compare both changes with the common starting point
Identify the common ancestor of the two agent branches. If both branch tips are available, obtain it with:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsgit merge-base agent-a agent-bThen compare each branch with that base:
git diff <common-base> agent-a
git diff <common-base> agent-bDuring an in-progress merge, the incoming commit is commonly available through MERGE_HEAD; compare the current branch and that incoming tip with the merge base rather than relying on a single conflicted file.
Map behavior, not just names
For each apparent duplicate, answer:
- Do both implementations serve the same caller and contract?
- Does one include validation, authorization, error handling, performance safeguards, or edge-case behavior missing from the other?
- Which public API, database schema, event name, or configuration key is already depended on?
- Are both migrations or startup hooks safe to run together, or would they execute the same operation twice?
- Which tests cover unique cases, and which merely repeat the same assertion?
Choose the stronger implementation only when its behavior subsumes the other. Otherwise combine the useful parts into one implementation and make the contract explicit. Rename misleading symbols, remove dead code, and update call sites so there is one obvious path for future fixes.
Rank #4
Consolidate safely
- Write down the intended behavior in terms of inputs, outputs, side effects, and failure cases.
- Select the canonical function, module, component, or migration location.
- Move missing logic from the other implementation into that location, resolving differences in types, defaults, and error semantics.
- Update every caller with repository-wide search. Do not rely on the compiler to find dynamic references, configuration strings, documentation examples, or generated clients.
- Delete the redundant implementation and its obsolete tests only after equivalent coverage exists.
- Run focused tests, then the project’s broader checks. Inspect the final diff for accidental API or schema changes.
Keep a short commit or pull-request note explaining why one implementation became canonical. That context prevents a later agent from recreating the removed version.
Use a visual merge tool when it improves review
Git can launch an external resolver with git mergetool. A three-pane tool shows the base, current side, and incoming side while you edit the result. KDiff3 is one example supported in Git’s documentation, but capabilities, keyboard shortcuts, platform support, and licensing vary by tool and version.
Prefer manual editing when the conflict is small, structural, or easier to explain in code review. Prefer a visual tool when many related hunks must be reconciled and the tool clearly labels all three versions. In either case, inspect the resulting diff and run tests; accepting every highlighted change is not a resolution strategy.
Abort a merge that should not proceed
If you discover that the wrong branch was selected, the merge target is incorrect, or the working tree has become too confusing to repair safely, use:
git merge --abortGit documents this as an attempt to return to the pre-merge state. It cannot guarantee recovery of every change made while the merge was in progress, especially if unrelated edits were mixed into the same files. Before aborting, copy or commit valuable independent work elsewhere and verify the result with git status.
After an abort, clarify the integration plan, create a clean starting point, and retry with smaller, better-scoped changes. Aborting is a recovery action, not a substitute for deciding which behavior belongs in the final branch.
When the duplicate is already committed
First determine whether the duplicate commit exists only in one developer’s local branch or has been pushed to a shared repository. The safe history operation depends on that distinction, your branch policy, and whether other commits depend on it.
Best Value
- Local-only work: coordinate with the author, compare the commits with their common base, and choose an agreed history-editing method only after making a backup reference.
- Shared or published work: avoid rewriting history unilaterally. Agree on a corrective commit or an approved team procedure, then communicate which implementation is canonical and which callers changed.
Do not apply a reset or rebase command merely because it appears to remove duplicate lines. Those commands can invalidate collaborators’ references and hide the point at which behavior changed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Prevent collisions when delegating work
Assign narrow ownership
Give each agent a task with an explicit expected result and file boundaries. For example, one agent can change the API contract and tests while another updates an isolated adapter, but both should know the order in which the contract and adapter will be integrated. Avoid having multiple agents independently edit the same file unless that overlap is intentional and coordinated.
State ownership for shared interfaces, generated files, database migrations, configuration, and documentation. A task such as “improve authentication” is too broad; “add token-expiry validation in the service layer, update its tests, and do not change the public interface” gives an agent a reviewable boundary.
Share contracts before implementation
Before agents start, record function signatures, event payloads, schema changes, error codes, and naming decisions that must remain compatible. If two tasks require a shared interface, assign one owner for the contract and tell the other agent to build against that agreed shape. This avoids two locally reasonable but incompatible APIs.
Use isolated worktrees when available
A Git worktree is a separate working directory associated with the same repository. You can create one for a branch with:
git worktree add ../agent-a agent-aEach agent then edits its own directory, so uncommitted files cannot overwrite one another in the same checkout. Worktrees still share repository references and do not make final integration conflict-free; the branches can modify the same logical code and must still be reviewed and merged.
| Approach | Uncommitted-file isolation | Sharing repository state | Integration overhead | Best fit |
|---|---|---|---|---|
| Separate worktree per agent | High: each agent has a distinct directory | High: branches and objects remain in the repository | Moderate: changes still need review and merge | Parallel tasks with enough disk space and runtime support |
| One shared working directory | None: edits can overwrite or obscure one another | Immediate, but fragile | Low at first, potentially high during recovery | Short, serialized tasks with explicit handoffs |
The isolated-copy model described for multi-agent coding environments reduces direct workspace collisions. It does not prove that the agents’ final changes are semantically compatible.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Review each diff before integration
Require every agent to report the files changed, assumptions made, tests run, generated outputs, and known follow-up work. Review the diff against the task rather than judging only whether the branch compiles. Look for duplicated helpers, parallel configuration keys, overlapping migrations, changed defaults, and tests that validate different contracts.
Integrate in a deliberate order. Land foundational interfaces before dependent adapters, and merge schema changes with the code that consumes them according to the project’s migration policy. After each integration, run the project’s own checks instead of waiting until all branches have been combined.
Quick Recap
A practical decision table
| Situation | First action | Resolution principle | Verification |
|---|---|---|---|
| Both sides changed the same lines | Inspect markers and stages 1–3 | Compose the intended behavior manually | Diff, focused tests, full checks |
| One side edited, the other deleted | Read callers and feature requirements | Keep or delete the file deliberately | Search references and build |
| Rename plus edits to the old path | Inspect both paths and references | Carry valid edits into the chosen path | Import, packaging, and test checks |
| Binary or generated-file conflict | Identify the source of truth | Choose the binary or regenerate it | Reproducible generation and validation |
| Two implementations compile separately | Compare both diffs with the common base | Consolidate one canonical behavior | Call-site search and regression tests |
| Merge direction is wrong | Protect valuable uncommitted work | Abort and restart with a clear plan | git status and clean branch state |
Final checklist before declaring the integration complete
git statusshows no unmerged paths and no unexplained files.- All conflict markers have been removed from source, tests, and generated text.
- Every resolved file was reviewed with
git diffafter editing. - Base, current, and incoming intent was considered for each textual conflict.
- Edit/delete, rename, binary, and directory decisions were made explicitly.
- No broad “ours” or “theirs” option discarded work without a documented reason.
- Duplicated implementations, configuration keys, migrations, and tests were compared semantically.
- Call sites, dynamic references, documentation examples, and generated clients were checked.
- Formatters, type checks, focused tests, and the project’s broader checks pass.
- The final commit or merge message explains the integration when future agents will need that context.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
