$ git checkout feature/myfeature
$ git rebase origin/master
...
<resolved conflicts>
...
$ git rebase --continue, git rebase --continue, …
$ git push -f origin feature/myfeature
As the referenced StackOverflow discussion describes:
“When performing a merge, ours refers to the branch you're merging into, and theirs refers to the branch you are merging from. So if you are trying to resolve conflicts in the middle of a merge:
Use ours to accept changes from the branch we are currently on
use theirs to accept changes from the branch we are merging into.
When rebasing, ours and theirs are inverted. Rebases pick files into a "detached" HEAD branch. The target is that HEAD branch, and merge-from is the original branch before rebase. That makes:
ours the anonymous one the rebase is constructing, and
theirs the one being rebased;
Resolve conflicts using THEIRS when re-basing
So, suppose you’ve just checked out branch “feature/myfeature“, then kicked off the rebase “$ git rebase origin/master“, and merge conflict [ CONFLICT (content): Merge conflict in themes/themex/dist/css/main.css ] are raised, and you wish to have those changes introduced in “feature/myfeature“ override what’s in master branch, then you’d want to resolve conflicts using theirs. This is because when you’re merging “feature/myfeature“ into master, then you’re switched into the master branch and changes are replayed on top of that branch, and hence the theirs will now be referring to “feature/myfeature“.
I.e., rebasing replays the current branch's commits (one at a time) on top of the branch that we intend to rebase with.“
References
Git - confusion over terminology, “theirs” vs “mine”
https://stackoverflow.com/questions/31817210/git-confusion-over-terminology-theirs-vs-mine/31817910Restoring lost commits
http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html