5

Let's say we have project P1 which is developed by more than one developer.

Developer D1 checked master out as B1 and made changes. Developer D2 checked master out as B2 and made changes.

D1 merged B1 changes to master. Now D2 created a pull request, wants to merge master, but there are conflicts.

This conflict could be solved during the merge process using github's Resolve Conflict screen.

However, D2 is asked to Resolve Conflict within B2 branch and then create a pull request. How could D2 do this? Is this the way that should be done or conflicts should resolve during merges?

Thank you.

Mohamed
  • 71
  • 3
  • 7
  • 1
    Possible duplicate of [How to resolve merge conflicts in Git](https://stackoverflow.com/questions/161813/how-to-resolve-merge-conflicts-in-git) – evolutionxbox Feb 06 '19 at 19:32

2 Answers2

0
git checkout master
git pull
git checkout D2
git merge master
# Here are conflicts. Resolve conflicts and do git add on the conflicted files.
git commit
git push

Now you can do your merge request.

The way to think about this is like this. You started D2 from a master. Then D1 was integrated in master. In order for everything to be integrated you have to merge your changes from D2 in master, but the same operation will produce the same result if you merge the current master (with D1 in it) in your own branch (D2). After you resolve all the conflicts in your branch, then you have a version containing master (without D1 and D2), D1 and D2, but the only difference between D2 and master are just the changes made in D2 (now including the resolving of conflicts -- these are also changes). So in order to make master exactly like your D2, you can just merge D2 in master because all the changes and conflicts are accounted for. Does this make sense?

Cristian Bidea
  • 679
  • 4
  • 12
0

Yes, effectively b1 and b2 share the same history (i.e. master). b1 gets merged back into master and so then b1 is now finished with master is updated (that is the + in the diagram below.

Now its branch b2 who wants to merge on master (or push), but to ensure the merge goes smoothly first b2 needs to merge (or pull) the latest version of master. So you have conflicts - you need to resolve them, maybe re-test everything and then commit the merge onto your b2 branch.

Now b2 is ready to be merged into master - it will be a "fast-forward" merge meaning master will literally just be moved to your latest commit because it knows that you have done all the work already.

Crappy diagram:

           ---b2-------merge----
          /             /       \
master -------------+---------ff-merge--
          \         |
           ---b1---/
code_fodder
  • 15,263
  • 17
  • 90
  • 167