resolve-conflicts

Resolve Conflicts

Finish a stopped git merge or git rebase by understanding what each side meant, not by picking a side. If the operation targets the wrong base or cannot safely continue, preserve existing resolutions and report the problem before an authorized abort; aborting can discard conflict-resolution work. Never "take ours" unless history shows the incoming change is obsolete.

Workflow

1. Map the state: identify which operation stopped, the current and incoming commits, and every conflicted file before editing.

   git status --short                    # UU both modified; AU, UA, DU, UD: added or deleted on one side
   git diff --name-only --diff-filter=U
   git rev-parse -q --verify MERGE_HEAD  # merge only
   git rev-parse -q --verify REBASE_HEAD # rebase only
   

2. Read both intents: inspect the available index stages and operation-specific history before touching a hunk. Add/delete conflicts legitimately lack one or more stages; a missing stage is evidence, not a reason to restore a deleted file. During a rebase, ours is the branch being rebased onto and theirs is the commit being replayed.

   git show :1:<file>                    # common ancestor
   git show :2:<file>                    # ours; rebase target during a rebase
   git show :3:<file>                    # theirs; replayed commit during a rebase
   git log --merge --oneline -- <file>   # both sides' commits touching the file; Git 2.45+ also covers rebase, cherry-pick, revert
   git show REBASE_HEAD -- <file>        # rebase: the commit currently being replayed
   

3. Resolve semantically: write the code that satisfies both intents (renamed function plus new caller, both new tests, merged config keys). When intents are incompatible, keep the one matching the merge's goal and record the trade-off in the commit body. Do not invent new behavior, and remove every <<<<<<<, =======, >>>>>>> marker.
4. Continue: stage the resolved files and resume; repeat per commit during a rebase.

   git add <file>...
   git rebase --continue   # or: git merge --continue
   

5. Prove it: Run the repository's owning gate (e.g. mise run all); when the tree carries unrelated changes, apply the dirty-tree rule. Fix what the merge broke before pushing.
6. Push only when already authorized: a rewritten private branch may need git push --force-with-lease; resolving conflicts alone does not authorize that history update, and never force-push a shared branch (main, or one others build on), merge into it instead.