During a git rebase conflict, which side is "ours" and which is "theirs", and why?

## The rule, stated precisely `ours` always means *the side that is currently checked out*, and `theirs` always means *the side whose changes are being applied to it*. That single definition never changes. What changes is which of your two branches occupies which role. In a merge on `feature`, HEAD is `feature`, so `ours` is `feature` and `theirs` is `main`. In `git rebase main` while on `feature`, Git first checks out `main`'s tip (detached), then applies your `feature` commits one at a time on top of it. HEAD is therefore on the *upstream* side, so `ours` is `main` plus already-replayed commits, and `theirs` is the `feature` commit currently being replayed. The labels have not flipped meaning; your branches have swapped seats. ## Why rebase works that way Rebase does not move commits; it re-creates them. To re-create a commit on a new base, Git must first *be* on that new base, then apply the commit's change as a patch. That is a cherry-pick, and a cherry-pick's three-way merge treats the commit's parent as the base, the commit as the incoming change, and the current HEAD as ours. Every rebase is a sequence of these, which is also why a rebase can stop on a conflict once per commit rather than once for the whole operation. ## Concrete consequences - `git checkout --ours <file>` during a rebase discards **your** changes to that file and keeps the upstream version. `--theirs` keeps your version. This is the single most common way people destroy their own work mid-rebase. - The conflict-marker labels reflect the same inversion: the block labelled `HEAD` is the upstream-plus-replayed state, and the closing label carries the hash and subject of *your* commit being replayed. Reading those labels rather than assuming is the reliable habit. - Strategy options that favour one side follow the same seat assignment, so a preference you would express one way in a merge must be expressed the other way in a rebase. ## How to keep it straight under pressure Three checks work without memorising anything: 1. Ask what is checked out right now. During a rebase, HEAD is on the new base. Whatever HEAD is, that is `ours`. 2. Read the marker labels. The closing `>>>>>>>` label names a commit; if that commit is one of yours, you are in a rebase and your work is the `theirs` side. 3. Prefer resolving by editing the file to the content you want rather than by grabbing a whole side. Editing is side-agnostic and immune to the inversion. ## Why the inversion feels wrong The emotional model is "I am rebasing *my* branch, so my branch is ours." The mechanical model is "Git is currently sitting on the new base, applying patches from elsewhere." The words follow the mechanics, not the intent. Once you internalise that rebase means *replay my commits somewhere else*, the seating becomes obvious: to replay them somewhere else, you first have to go there. ## The same inversion elsewhere Because the rule is about what is checked out, anything built on cherry-pick shows the same behaviour. Applying someone else's patch onto your branch makes your branch `ours` and the patch `theirs` — which reads naturally. It is specifically the case where the incoming patch is *your own commit* that surprises people, and that is exactly the rebase case. ## Practical safety Mid-rebase state is fully recoverable: `git rebase --abort` restores the branch to where it started. If you suspect you resolved a hunk by grabbing the wrong side, aborting and restarting is cheap and far safer than trying to reconstruct the lost lines afterwards. If the same conflicts recur every time you rebase a long-lived branch, recording resolutions so Git can replay them saves the repeated decision — but only after you have made the decision correctly once.