如何讓編碼智能體解決合併衝突，同時保留修改意圖

Hand the agent the purpose of both changes, keep a restore point and check the combined result. Resolving a conflict is not just removing markers from a file. You need to verify that the behavior each side meant to keep still exists.

Identify what is actually clashing

A conflict means Git could not join some of the changes automatically. It does not decide which behavior is correct. Both sides can be right separately and still require a new decision when combined.

An illustration: one branch adds a permission check before saving. Another changes saving to prevent duplicate actions. Choosing one side's version can silently delete the other's protection even if the code compiles. This is a synthetic example, not an incident recorded at a client.

Keep a state you can explain and restore

Before you start, check which branch you are on, which files changed and what is not yet saved. Git's documentation warns against merging with significant unsaved local changes. git merge --abort tries to return to the state before the merge, but does not guarantee restoring such local changes in every situation.

Ask the agent to identify the state and report it before acting. Do not let it delete local work to "clean up" the working tree. A local commit or another form of saving should preserve the material, per the team's practice. Secrets are not material that goes into a commit.

Give two intents, not just two files

Attach the reason for the change on each side, links to the discussion or PR description, and the tests that represent the behavior. Read the nearby code with the agent. A variable rename can hide a change in a function's contract.

A suggested request to the agent:

Explain the intent of each side and where they clash. Propose a result that preserves both sides' requirements. If they contradict, stop with a focused question. Fix only the agreed conflict. Show a diff of the resolution and actual test results. Do not push or merge remotely without a separate instruction.

This sets an important boundary: the agent can prepare a local fix, but a product decision or a new permission requires whoever owns it.

Beware of automatically picking a side

In Git's documentation, the ours option inside the merge strategy prefers the current side in conflicting parts. The theirs option prefers the other side. These are technical resolutions that can lose a requirement.

There is also a merge strategy called ours, which ignores the other side's changes and keeps the current side's tree. It is different from the option that prefers only conflicting parts. So a command that looks like a shortcut can change the meaning of the whole merge.

As a working default, ask for an explanation before a sweeping choice. If the team decided to drop a change, record what was decided and why, instead of hiding the concession behind a "resolved" mark.

Test the combination, not just the markers

git diff --check warns about conflict markers or whitespace errors added in the change. Per Git's documentation it returns a non-zero exit code when problems are found. It does not check that a permission, a duplicate-prevention or any other behavior was preserved.

Test a scenario representing each side, then a scenario that exercises both together. In the permission-and-save example, test an authorized user, an unauthorized user and a repeated action. The list is an illustration and depends on the code's real contract.

Alongside automated tests, go over the diff against the documented intents. Vanished conflict markers are a step in the process, not evidence of success.

Return a short report before continuing

At the end the agent should present which conflicts were handled, what was kept from each side, which commands were run and what was not checked. Any additional change needed to complete the join should be visible on its own.

If the result does not preserve both requirements, go back to a decision. The agent's role is to take the mechanical work off, without turning a business or engineering choice into something that happens by accident inside a file.

Sources: Git: merge, conflicts and abort limits, Git: what diff --check does. Originally published in Hebrew on ofershap.github.io.