目前我一直在使用git和github编写rails应用程序。我通常是独自工作，但在我的最新项目中，我正在与第二个开发人员合作。我正在尝试找出与另一个用户协作的标准方法。
目前，我让他fork我的gitrepo，然后只需在准备好更改时提交pull request。这还不错，除了我编写的代码更多之外 - 当队列中有他要推送的更改时，其中许多会失败（即使他从上次推送我的代码以来没有进行任何更改）。
整个过程似乎更高效的方法是每次重新fork，这让我想我们可能做错了什么。我们应该使用分支而不是fork吗？或者同时使用fork和分支？
谢谢！
第二个开发者应该先将GitHub存储库拉到他的本地存储库中，解决任何冲突。
然后他可以发起拉取请求。
拉取请求的想法仍然是提交补丁，这些补丁将是快进的（易于应用于您的GitHub存储库）。
在发起拉取请求之前，通过先在本地解决任何冲突来实现这一点。
由于 Git 是一种灵活的工具，因此有许多 Git 工作流程可供选择，但简单的工作流程是拥有一个“主”分支和一个“开发”分支。您可以直接将代码推送和拉取到您的存储库中，而无需在 GitHub 上进行分叉，并且您的合作者也不必不断提交 Github 拉取请求。
您可以在开发分支上进行大部分本地提交，但经常从远程开发分支拉取以合并彼此的代码 - 在这个阶段，您可以处理合并冲突，然后再推送到远程。
较少情况下，您可以拉取主分支并将其与开发分支合并。这样做的想法是主分支更稳定，随时可以准备发布，因此不会在其上进行活动开发。就是这样。
如果您想进一步发展，可以从开发分支创建“功能分支”，但原则是相同的-向上合并到开发分支，然后向上合并到主分支。
重要的是要经常同步（合并）您的工作，否则您的代码库的副本之间的差异可能会更大，这意味着冲突的机会更大。如果您继续遇到冲突，请更频繁地推送和拉取，以便差异更小且更易于处理。
如果你们都在大量地处理同一个文件，那么冲突就很可能发生。在这种情况下，有时候最好是有条不紊地将工作分成不同的特性，以更改代码库中的不同部分（文件），这样你们就不太可能互相干扰。
记得在拉取之前提交本地更改，否则更改将被视为处于“暂存”状态，并且在拉取期间不会自动合并。幸运的是，Git相当宽容并且非常擅长处理合并冲突。
