Let’s see if I get this wrong after 25 years of git:

ours means what is in my local codebase.

theirs means what is being merged into my local codebase.

I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

▲ marcellus23 2 hours ago | parent | next [-]

That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense.

What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?

	▲	IgorPartola 2 hours ago \| parent [-]
		> What if I'm rebasing a branch onto another? Just checkout the branch you are merging/rebasing into before doing it. > Or if I'm applying a stash? The stash is in that case effectively a remote branch you are merging into your local codebase. ours is your local, theirs is the stash.

▲ clktmr 2 hours ago | parent | prev | next [-]

The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.

	▲	IgorPartola 2 hours ago \| parent [-]
		Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts. As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits from the feature branch clogging up my main history. Nobody should ever need to revert main to that state and if I really really need to look at that particular code commit I can still find it in the feature branch history.

▲ em-bee 2 hours ago | parent | prev [-]

a better (more confusing) example:

i have a branch and i want to merge that branch into main.

is ours the branch and main theirs? or is ours main, and the branch theirs?

▲ IgorPartola 2 hours ago | parent [-]

I always checkout the branch I am merging something into. I was vaguely aware I could have main checked out but merge foo into bar but have never once done that.

▲ Sharlin 2 hours ago | parent [-]

  git checkout mybranch
  git rebase main

A conflict happens. Now "ours" is main and "theirs" is mybranch, even though from your perspective you're still on mybranch. Git isn't, however.

▲

IgorPartola an hour ago | parent [-]

Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.

	▲	ljm an hour ago \| parent [-]
		I have met more than one person who would doggedly tolerate rebase, not even using rerere, instead of doing a simple ‘git merge --no-ff’ to one-shot it, not understanding that rebase touches every commit in the diff between main and not simply the latest change on HEAD. Not a problem if you are a purist on linear history.