1

Scenario is that I have three branches. main, A, and B.

A and B are feature branches created off main at the same time. I updated file 1 in branch A and B.

I then created a pull request from A into main without any conflicts. Now when I try to create a PR from B into main I get an error about having merge conflicts that need to be resolved. I am using the VSCode GitHub Pull Request extension and what it shows me when I click on a modified file is in the screenshot below.

enter image description here

I do not see any way to accept incoming changes or to keep current changes but I have seen this when trying to rebase. Is there anyway to see this so that I could fix conflicts on each file and just approve or delete the conflicted lines?

Additionally, after the first PR approval from A into main if I try to merge B into main it shows me old data from file 1 on the image above at the left hand side. It does not show updated information on that file from what is in my remote repository after the PR approval.

Is the only way to fix this through running a rebase? It has become a bit of a pain because I have to go through 50 to 100 conflicts that need to be resolved in the rebase. It looks like these conflicts during each git rebase --continue are on generally the same set of files with just different commits.

rk92
  • 551
  • 4
  • 21
  • 1
    If you're willing to abandon Visual Studio for doing Git work, the problem becomes easier as there are many Git tools for this (and then [tag:git] as a tag here makes sense). If not—if you need to have this happen *in* Visual Studio—keep the [tag:visual-studio-code] tag and drop the [tag:git] tag. – torek Jun 15 '21 at 12:23
  • @torek Sure thing, I removed the VSCode tag. What I ended up doing was merging main into my feature branch locally, fixing merge conflicts, then pushing the feature branch to remote and then there were no more merge conflicts showing up on the PR. I was able to approve the PR. Does that seem like an okay approach? Does this do anything negative? – rk92 Jun 15 '21 at 14:51
  • 1
    Some people dislike the general idea of merging `main` into a feature branch. I'm not one of these people myself, but if you're in (or working with) a group that says that one should only merge feature branches into `main` (never `main` into feature branch), you might want to pick a different approach. Otherwise it's OK—it's a matter of who expects what, really. – torek Jun 15 '21 at 14:55
  • @torek Thanks much. I was going based off some command line tips that GitHub provided to resolve the conflict. So if groups are against merging main into a feature branch you could checkout feature branch, merge main, resolve conflicts and test, DON'T COMMIT OR PUSH CHANGES, checkout main, merge feature into main, re-resolve conflicts based on testing in feature branch, then push? – rk92 Jun 15 '21 at 15:10
  • @torek If you merge main into feature, resolve conflicts, commit and push from feature does that essentially make the feature = main? – rk92 Jun 15 '21 at 15:12
  • 1
    I've worked with a group whose workflow was always "rebase your feature so that it applies cleanly to main". This particular workflow is annoying if the main branch is highly active. I actually prefer a feature-bubble workflow myself, but to use that, you need to be allowed to do the merge yourself (to main) in your own local repository, then push that merge itself directly to GitHub (to the shared repo main), and that requires a lot of trust. – torek Jun 15 '21 at 15:42
  • 1
    And: yes, after merging main into feature, you have a commit that could serve as the new main. This produces what some people call a "foxtrot merge" though, and it has the drawback that `--first-parent` no longer follows the main branch. See also [this post](https://stackoverflow.com/q/35962754/1256452). – torek Jun 15 '21 at 15:44
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/233804/discussion-between-rk92-and-torek). – rk92 Jun 15 '21 at 15:49

1 Answers1

0

Thanks @torek, discussion above in the OP may be useful to others.

Couple of ways to solve this, main confusion was with what a PR and merge were doing on either the git or GitHub side.

From the CLI I was able to run git checkout <FEATURE>, git merge main, then resolve conflicts in a testing manner. Optional to commit and push back to remote. If you do push to remote the PR will update saying no conflicts are present if all conflicts were fixed. PR can be approved.

Alternatively if you don't want to merge main into FEATURE to test you can run git checkout main, git merge --no-ff <FEATURE>, resolve conflicts again, commit and push. PR for me automatically merged.

rk92
  • 551
  • 4
  • 21