'After merging Master branch, fixing conflicts, removing other files from the merge, GIT is treating files in my feature branch as latest
So, trying to be proactive knowing that there were going to be some merge conflicts when merging my feature branch into Master, I went ahead and merged Master to my branch locally, fixed the conflicts, and here is the critical part---I only ended up committing the files merged from Master that I'd been working on, and removed all the rest from the commit. Looking back of course, I shouldn't have done this... I didn't realize that it was going to treat those files that I removed as the latest changes on my feature branch.
So, attempting to do a pull request into Master, I realize that all of those files I took out of the original merge were trying to overwrite newer files in Master.
This turned out to be OK, I was able to take my commit on the feature branch BEFORE the merge and clone a new branch from there. So, a learning experience. My question is... was there another better way to have handled this? I'd tried reverting the merge commit but somehow it was still trying to overwrite all of those same files when I looked at merging to Master.
Thanks
Solution 1:[1]
My question is... was there another way to do this?
It depends what "this" is:
The correct way to deal with a merge conflict is to edit the conflicted files to resolve the conflict, add them, and say
git commit.The correct way to undo a bad merge is to reset hard back to the commit before the merge commit.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | matt |
