I would often find myself with a couple of files having a merge conflict when I'm either rebasing, merging or cherry-picking
let's say I'm working on my feature branch called foo and there are some additional changes on the main branch that I want to incorporate into my branch. But I already made changes to my feature branch and commited them.
So my branches now look something like this :
If Someone has made a change on the exact same line of code in the exact same file as I did, in one of the commits C, D or E then I will definitely have a merge conflict thrown at me, when I run:
Sometimes I just want the version of the file from main and then I'll amend my latest commit / make a new commit to make my changes again in that file.
In this case I would do :
or
or
--ours and --theirs are inverted for rebase lol. Why?
when we do a rebase, internally
git rebase main (in my case, i.e, the example above) translates to :
git checkout main
git cherry-pick F
git cherry-pick G
git cherry-pick H
.... and then some renaming logic to finish the rebase
so to pick the files from main, you actually have to use the --ours flag
If I know before hand that there are going to be merge conflicts and I want all conflicted files to be from main
git merge -X theirs main
git cherry-pick -X theirs b5fde68
git rebase main -X ours