resolve-merge-conflictslisted

# Resolve merge conflicts (non-destructively) Resolve git conflicts so that **both sides' intent survives**, verify the result, and **stop and ask a human** the moment a safe resolution isn't obvious. The git mechanics are the easy part; the danger is *silently dropping someone's work* — a blind "take theirs," a clean-looking textual merge that's logically broken, or a force-push over a teammate's commits. Command recipes live in [`reference/playbook.md`](./reference/playbook.md) (load on demand). This body is the decision rules. ## First: rebase or merge? You update a feature/PR branch against its base one of two ways. Either is fine — pick by context, not dogma: | | `git rebase origin/main` | `git merge origin/main` | | --- | --- | --- | | History | linear (replays your commits) | adds a merge commit | | Conflicts | may re-hit the **same** conflict per replayed commit (turn on `rerere`) | resolve **once** | | Push after | `--force-with-lease` (rewrites your branch) | normal push | | Best for | your **own** unshared PR branch | a branch **others** also commit to | In a **squash-merge** repo (see [`git-trunk-branch-and-pr-automation`](../git-trunk-branch-and-pr-automation/SKILL.md)) the feature branch's history is flattened at merge anyway, so a merge commit on the branch is harmless — when a rebase keeps re-conflicting, **merge instead** and resolve once. **Never rebase a branch other people are actively committing to.** ## The non-negotiable safety rules 1. **Never