That's exactly why the author included it. Your definition seems appropriate at first and is probably what most people assume: "ours" refers to "my current branch" (HEAD), and "theirs" refers to "the other branch".

This breaks down during rebase, where the terminology gets reversed. The definitions are more accurately:

- "Ours" refers to "the branch whose HEAD will be the 1st parent of the merge commit" (during merge) or "the branch who will get commits applied on top of its HEAD" (during rebase)

- "Theirs" refers to "the branch whose HEAD will be the 2nd parent of the merge commit" (during merge) or "the branch whose commits will be applied on top of the other branch" (during rebase)

This gets a little more complicated during "octopus merges", where there are multiple "theirs" branches.

I'm constantly having to double-check directionality for pretty much everything in Git. I find none of the terminology or ordering intuitive, and never trust myself to have remembered it correctly. Ditto whether various commands that take or imply ranges are inclusive or exclusive.

Ah, but it's not switched! Remember that rebase essentially replays commits against a different branch/base commit:

e.g. if you have your branch `feature-1` and want to rebase it on `main`, then you would do `git checkout feature-1; git rebase -i main`

Git will then switch to main (that's "ours" now) and then it will replay the changes from `feature-1` on top of it (that's "theirs" now) - like cherry-picking all your commits, but in sequence (and not actually merging them in `main`)

> Remember that rebase essentially replays commits against a different branch/base commit

This is exactly the reason that git is hard. Its abstractions are so leaky that you'd think it's interface is designed to be a sieve. I really like the underlying model git uses, but the actual CLI does a terrible job of providing mechanisms to use it to the point where you have to pay far too much attention to the internal model to be able to avoid footguns. It's an indictment of a poor API when the best way to figure out how to do something isn't to search the docs but to figure out how to express the thing you want to do as an operation on the underlying model and then Google that to find the invocation that happens to map to that operation (and half the time, it's not even it's own subcommand; it's just some obscure flag to a grossly overloaded subcommand like `checkout`).

I can't quite find it, but there's a video on git internals, and how you can make commits without using the git cli, by directly manipulating .git folder. That really helped me deal with certain idiosyncracies of the git cli (either I guess a hacked-together sequence of git cli commands, or i know what to nuke)