Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git conflicts in pull requests

I have 2 branches - master and develop

I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.

However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.

As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:

git fetch origin master
git checkout develop 
git merge FETCH_HEAD
git commit
git push origin HEAD

And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?

like image 862
dissidia Avatar asked Sep 29 '14 09:09

dissidia


People also ask

What are Git conflicts?

Git can handle most merges on its own with automatic merging features. A conflict arises when two separate branches have made edits to the same line in a file, or when a file has been deleted in one branch but edited in the other. Conflicts will most likely happen when working in a team environment.


1 Answers

What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.

You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.

By doing it the first way,

  1. you make a better audit trail by merging to master on GitHub, using the PR;
  2. you give your team a chance to review your code after the merge, before it lands on master; and
  3. if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.
like image 157
Peeja Avatar answered Sep 20 '22 06:09

Peeja