1

I created a new feature branch and then made some changes to it and pushed the branch. Then I have checked out master branch and tried to merge my feature branch back in the master branch. While doing so, vscode showed some merge conflicts. Then I recall I did not want to merge some of the changes in feature branch in the master branch. So I unstanged those files while merging others manually. Then I committed the merge. However when I run the (merged) app, it showed those changes too which I unstanged / removed during manual merge.

What I might be doing wrong? What is recommended way to do this (discarding some changes in feature branch while merging it in master)?

Update - some more details

This is a feature branch commit:

enter image description here

I did not want to merge navbar.css and NavBar.jsx from Screens folder. So I unstaged them during merge.

Now this is a merge commit:

enter image description here

As you can see, only ProfileButton.jsx from Screens folder is in the merge. So navbar.css and NavBar.jsx are indeed not included in the merge. Still when I run the app, the contents from these files get shown.

Update 2

I have not yet pushed the changes. And those files are still listed as unstaged. So these files are still present in my workspace. Is that why I am getting this issue? If yes, how can run the app with desired merge changes before pushing?

MsA
  • 2,599
  • 3
  • 22
  • 47
  • https://stackoverflow.com/questions/10935226/git-interactive-merge – Konrad Jun 19 '23 at 11:54
  • @Konrad please check update 2. – MsA Jun 19 '23 at 12:06
  • You can stash the unstaged changes – Konrad Jun 19 '23 at 12:12
  • 1
    Unstaging a change does not revert the change. – j6t Jun 19 '23 at 14:45
  • "vscode showed some merge conflicts. Then I recall I did not want to merge some of the changes in feature branch in the master branch. So I unstanged those files while merging others manually. Then I committed the merge" I'm not sure what "I unstanged those files while merging" means, but making significant changes while resolving a merge conflict is a very bad idea, so bad that it has a name: an _evil merge_. The correct procedure is to resolve the conflicts and that's all, and _then_ if there's something you don't like about the result, you can make a new commit that fixes the problem. – matt Jun 19 '23 at 17:05
  • What I would suggest is that you start over. Since you have not pushed, just reset hard to before you performed the merge (i.e. before "tried to merge my feature branch back in the master branch"). Now do the merge again and behave more coherently this time. – matt Jun 19 '23 at 17:07
  • By the way your screen shots are uselessly tiny. They communicate no information at all. – matt Jun 19 '23 at 17:08

0 Answers0