Git Fork/Merge Conflicts?

Question

I'm still new to version control and Github as a whole. Something's quite confusing to me and I can't seem to wrap my head around it. Imagine a scenario where we're two guys working on the same rails app project. Guy A has the master repo, Guy B is the one who forked the repo. Now Guy B creates a new feature that didn't exist on the app. In doing so, he had to edit, and in some cases move around, some files to get the desired result.

Meanwhile Guy A is working on a very similar feature and also has to edit and move very similar files, but with very different source codes. Or maybe he's working on a different feature that has him editing those same files, but with different source codes. Now Guy B submits a pull request and Guy A also has to merge the feature he created into the master branch. How does github reconcile these same files that have been altered in different ways by two different guys?

Answer 1

When I've worked in a multi-user project this is how the workflow goes:

• Guy A makes changes in local repo -> Push changes to remote repo

• Guy B makes changes in local repo -> Push changes to remote repo (It would fail here)

• Guy B does a git fetch followed by git merge or a git rebase so that his changes are merged with the changes from the remote. Guy B should immediately push these changes to the remote

• Guy A does some more changes in his local repo -> Push changes (It would fail again). He follows a similar set of steps to Guy B on merging or rebasing.

And speaking in Github terms, the concept of pushing changes to remote repo is handled as a pull request in github. When someone sends a pull request to some branch in some repo, it is the requester's responsibility to do the merge/rebase of his changes against this target and then send the pull request.

If the user receiving the pull request sees a lot of conflicts either because the requester didn't take enough pains to do the merges or because there were prior pull requests he had to take care of, which now causes conflicts, then the owner can ask the requester to send an updated pull request on top of the latest changes.

In other words, the person receiving the pull request would usually be happy only to accept fast-forward merges, but there are few minor exceptions.

Answer 2

Github uses merges for pull requests. Sometimes, manual merges need to be done on Guy B's repo to resolve conflicts that pull request merges cannot handle. Sometimes rebasing may work a bit better but your mileage may vary.

Personally my method is that person that adds his/her code last is the one in charge of merging/rebasing before pushing back to authoritative repo or branch through either pull requests or manual integration.