Git rebase - prefers older data in files with conflicts?

sir-haver 0
Viewed 36

I'm on a new branch and made some changes to files. Meanwhile the master branch has changed too, so to incorporate those changes in my branch I would like to use rebase. I checkout the master branch and pull, then going back into my new branch, I do

git rebase master

Then I'm getting some conflicts, in those files with conflicts, vs-code allows me to resolve the conflicts, however in other lines (in those same files with conflicts), where there are no conflicts, I see that git overwritten my new code (which I committed), and it was overwritten by the older code of my master. Why is that so? Isn't it supposed to be the other way around? I'm rebasing master my new commit should be on top - therefore why my code is being overwritten by the older one from Master?

git
1 Answers

if the branch is made up of many revisions that will be rebased, you might face conflicts on any of the revisions that will be applied and so it's normal that you won't see the final version of the files (with all the changes of the feature branch applied). So just consider the conflicts, add the files when you are done and run git rebase --continue so that rebase can apply the pending revisions.

It's still possible that you might want to look at other places, there's nothing that forbids it, just consider that only a subset of the changes might have been applied up to that point (if the conflicted revision is not the last in the rebase).

eftshift00
Related