我对版本控制和整个 Github 还是很陌生。有些事情让我很困惑，我似乎无法理解它。想象一个场景，我们两个人在同一个 Rails 应用程序项目上工作。Guy A 拥有主仓库，Guy B 是 fork 仓库的人。现在 Guy B 创建了一个应用程序中不存在的新功能。这样做时，他必须编辑一些文件，在某些情况下还要四处走动，才能得到想要的结果。
与此同时，Guy A 正在开发一个非常相似的功能，并且还必须编辑和移动非常相似的文件，但源代码却非常不同。或者，也许他正在开发一个不同的功能，让他编辑这些相同的文件，但使用不同的源代码。现在 Guy B 提交了一个 pull request，而 Guy A 还必须将他创建的功能合并到 master 分支中。github 如何协调这些由两个不同的人以不同方式更改的相同文件？
Github 将合并用于拉取请求。有时，需要在 Guy B 的 repo 上进行手动合并，以解决拉取请求合并无法处理的冲突。有时变基可能会更好一些，但你的里程可能会有所不同。
就我个人而言，我的方法是最后添加他/她的代码的人是负责合并/变基的人，然后再通过拉取请求或手动集成推回权威仓库或分支。
当我在一个多用户项目中工作时，工作流程是这样的：
Guy A 在本地 repo 中进行更改 -> 将更改推送到远程 repo
Guy B 在本地 repo 中进行更改 -> 将更改推送到远程 repo（这里会失败）
Guy B 执行 a git fetchfollow bygit merge或 agit rebase以便他的更改与来自远程的更改合并。Guy B 应该立即将这些更改推送到遥控器
Guy A 在他的本地 repo 中进行了更多更改 -> 推送更改（它会再次失败）。在合并或变基方面，他遵循与 Guy B 类似的一组步骤。
用 Github 术语来说，将更改推送到远程 repo 的概念pull request在 github 中处理。当有人向某个 repo 中的某个分支发送拉取请求时，请求者有责任针对该目标对他的更改进行合并/变基，然后发送pull request.
如果收到拉取请求的用户看到很多冲突，要么是因为请求者没有付出足够的努力来进行合并，要么是因为之前有他必须处理的拉取请求，现在导致冲突，那么所有者可以问请求者pull request在最新更改之上发送更新。
换句话说，接收拉取请求的人通常会很乐意接受fast-forward merges，但也有少数例外。