merge

# Merge A conflict is two intents meeting, not two texts disagreeing. Resolve it by understanding what each side was for. Always resolve; abandoning the operation returns the same conflict to the next person with less context than you have now. ## See the state Establish what is actually in progress before touching a file: ```bash git status git log --oneline --left-right --boundary HEAD...MERGE_HEAD mapfile -t conflicted < <(git diff --name-only --diff-filter=U) printf '%s\n' "${conflicted[@]}" ``` Record that list while the paths are still conflicted: once the markers are gone the same query returns nothing, and this is the list you stage at the end. A rebase and a merge present the sides in opposite orders, so confirm which operation you are in before reading any hunk. During a rebase the side labelled as yours is the upstream branch, and the side labelled as theirs is the commit being replayed. ## Find the intent For each conflicting file, find the primary source of both changes: ```bash git log -p --follow -- <path> ``` Read the commit messages, and where a commit points at a pull request or an issue, read that too. The wish that owns the work is the strongest source available in this repository: the criteria and the execution strategy say what the change was for in the author's own words. Keep reading until you can state each side's intent in one sentence. ## Resolve each hunk - Preserve both intents where they compose. Most conflicts are two independent edi...