我对版本控制和整个github还是个新手。有件事让我很困惑，我似乎无法把自己的头裹住。
想象一下这样一个场景：我们两个人在同一个rails应用程序项目上工作。盖伊A拥有主回购协议，盖伊B是负责回购协议的人。现在guy b创建了一个应用程序中不存在的新功能。在这样做的时候，他必须编辑，在某些情况下，移动一些文件，以获得所需的结果。
与此同时，guy a正在开发一个非常相似的特性，并且还必须编辑和移动非常相似的文件，但是使用非常不同的源代码。或者他正在开发一个不同的功能，让他编辑那些相同的文件，但是使用不同的源代码。现在guy b提交了一个pull请求，guy b a还必须将他创建的特性合并到master分支中。github如何协调这些被两个不同的人以不同方式更改的相同文件？
最佳答案
当我在多用户项目中工作时，工作流程就是这样的：
Guy A更改本地回购->将更改推送到远程回购
guy b在本地repo中进行更改->将更改推送到远程repo（这里会失败）
guy b执行agit fetch后跟agit merge或agit rebase的操作，以便将他的更改与来自远程的更改合并。伙计B应该马上把这些东西推到遥控器上
盖伊A在他的本地回购中做了更多的修改->推送修改（这将再次失败）。他在合并或重新定位上遵循了与B相似的一系列步骤。
用github的术语来说，将更改推送到远程repo的概念在github中被当作pull request处理。当有人向某个回购协议中的某个分支发送拉取请求时，请求者的责任是根据此目标合并/重新定位其更改，然后发送pull request。
如果接收拉取请求的用户看到许多冲突，或者是因为请求者没有花足够的精力进行合并，或者是因为他必须处理以前的拉取请求，这现在导致了冲突，那么所有者可以要求请求者在最新更改的基础上发送一个更新的pull request。
换句话说，接收拉取请求的人通常只愿意接受fast-forward merges，但很少有小的例外。