Resolve Merge Conflicts

The script does not fetch, commit, push, abort, or edit workflow Markdown. Refresh origin/main first only when credentials are available. After success, review the staged merge, run the repository’s final validation gate, then commit and push.

Why the marker scan matters

A source .md conflict resolved manually (by a human or an agent) can leave a stray conflict-marker line behind — most often the rarely-noticed ||||||| base (original) diff3 marker — inside a workflow’s YAML frontmatter. git diff --check only inspects lines touched by the current diff/staged hunks, so a marker already committed in otherwise-unchanged file content passes silently. The gh-aw compiler then parses the marker text as a literal YAML header option (e.g. invalid header option: "|||||| base (original)"), which fails compilation later — often in an unrelated scheduled recompilation run, far from the original merge, making the root cause hard to trace back.

Run the standalone check any time you suspect a workflow .md file went through manual conflict resolution, even outside this script’s merge flow:

It exits non-zero and lists the offending file(s)/line(s) if any marker is found, and does not modify the working tree.

Safety rules

• Never choose ours or theirs for compiled lock files; regenerate them.
• Never manually remove conflict markers from .lock.yml files.
• Never auto-resolve a source .md, Go, JavaScript, or other mixed conflict.
• If the script refuses a mixed conflict, resolve source conflicts on their merits, stage them, and rerun the same command. It will regenerate the remaining lock conflicts.
• Do not abort an existing merge unless the user explicitly requests it.