我还是版本控制和Github的新手。有些东西让我很困惑，我似乎无法绕过它。 想象一下，我们有两个人在同一个rails app项目上工作。 Guy A拥有主回购，Guy B是分配回购的人。现在Guy B创建了一个在应用程序中不存在的新功能。在这样做时，他必须编辑，并在某些情况下移动一些文件以获得所需的结果。
同时Guy A正在开发一个非常相似的功能，还必须编辑和移动非常相似的文件，但源代码却截然不同。或许他正在开发一个不同的功能，让他编辑相同的文件，但使用不同的源代码。现在Guy B提交拉取请求，而Guy A也必须将他创建的功能合并到主分支中。 github如何协调这些由两个不同的人以不同方式改变的文件？
答案 0 :(得分：1)
Github使用合并进行拉取请求。有时，需要在Guy B的repo上进行手动合并，以解决拉请求合并无法处理的冲突。有时候变调可能会有所改善，但你的里程可能会有所不同。
就我个人而言，我的方法是最后添加他/她的代码的人是负责合并/重新定位的人，然后再通过拉取请求或手动集成推回权威回购或分支。
答案 1 :(得分：1)
当我在多用户项目中工作时，这就是工作流程的方式：
盖伊A在本地回购中做出更改 - ＆gt;将更改推送到远程仓库
Guy B在本地回购中进行更改 - ＆gt;将更改推送到远程仓库（这将失败）
Guy B执行git fetch后跟git merge或git rebase，以便将其更改与远程更改合并。 Guy B应立即将这些更改推送到远程
Guy A在他的本地回购中做了一些更改 - ＆gt;推送更改（它会再次失败）。他在合并或重新定位时遵循与Guy B类似的一系列步骤。
用Github的术语来说，将更改推送到远程仓库的概念在github中作为pull request处理。当有人向某个仓库中的某个分支发送拉取请求时，请求者有责任对该目标进行其更改的合并/变更，然后发送pull request。
如果接收拉取请求的用户看到很多冲突，或者是因为请求者没有花费足够的精力来进行合并，或者因为先前的拉取请求他必须要处理，这现在会导致冲突，那么所有者可以要求请求者在最新更改的基础上发送更新的pull request。
换句话说，接收拉取请求的人通常只会接受fast-forward merges感到高兴，但几乎没有例外。