How to use the Git Merge Conflict Explainer.
A conflict resolution should preserve intended changes from both sides when they are compatible. Ask about business behavior when syntax alone cannot decide.
Make the workflow fit your task.
Read the conflicting versions and the surrounding code, then identify the intent of each change. Combine compatible behavior and ask for a decision where the requirements conflict, testing the resulting interaction afterward.
- What you provide
- Conflict markers and intended changes.
- What you get
- Conflict explanation and proposed merged draft.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Resolve this simplified HTML conflict: base button was <button type="button">Save</button>. Branch A changes its label to Save draft. Branch B adds disabled because submission is unavailable.
Completed example
<button type="button" disabled>Save draft</button> Both changes are retained: the new label and the unavailable state. Confirm when the application should remove disabled; the merged markup alone does not implement that state transition.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Is choosing ours or theirs always a complete conflict resolution?
It can discard a valid change from the other side. Compare intentions before selecting or combining content.
Why does a syntactically clean merge still break the feature?
The combined behavior may conflict even without markers. Check state, event handling and the requirements both branches were meant to satisfy.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑