所以目前我一直使用git和github编写rails应用程序。我通常独自工作，但在我最近的项目中，我正在与第二个开发人员合作。我正在试图找出与其他用户合作的标准方法。
目前，我让他拨打我的gitrepo，然后在准备好更改时提交拉取请求。这并没有那么糟糕，除了我编写更多代码 - 当fork队列中有变化让他推动时，他们中的许多都失败了（即使他上次推他的时候没有做任何改动）。
整个过程对他来说每次重新分配似乎更有效率，这让我觉得我们正在做错事。我们应该使用分支而不是分支吗？或者可能是叉子和树枝？
谢谢！
答案 0 :(得分：1)
第二个开发者应首先将GitHub仓库拉入他的本地仓库，解决那里的任何冲突。
然后他可以提出拉动请求。
master'）拉取请求的想法仍然是提交快速转发的补丁（易于应用于您的GitHub仓库）。
这是通过在提出拉取请求之前首先在本地解决任何冲突来实现的。
其他选择是将第二个开发人员声明为GitHub项目的“合作者”（他可以直接推送），但这不会改变“先拉”是必要的事实，以确保推动将是直截了当的。
答案 1 :(得分：1)
有许多git工作流程可供您使用，因为它是一个灵活的工具，但简单的工作流程是拥有“主”分支和“开发”分支。您可以直接推送到您的仓库，而无需在github上进行操作，也无需您的协作者不断提交Github拉取请求。
您可以在开发分支上进行大部分本地提交，但经常从远程开发分支下拉以合并彼此的代码 - 在此阶段您可以在推送到远程之前处理合并冲突
不太常见，你可以拉下master并将其与develop合并。这个想法是主分支更稳定，可以随时准备发布，因此不会发生主动开发。这就是它的全部内容。
如果你想更进一步，你可以从你的开发分支机构制作“功能分支”，但原则是相同的 - 合并'up'来开发，从那里'up'到master。
重要的是经常同步（合并）您的工作，否则您的代码库单独副本的差异可能会更大，这意味着更大的冲突机会。如果您继续发生冲突，请更频繁地推拉，以便差异更小，更容易处理。
如果您在同一文件上工作很多，则特别容易发生冲突。在这种情况下，有时需要进行组织并将工作划分为更改代码库不同部分（文件）的功能，这样您就不太可能互相踩到脚趾。
请记住在提取之前提交本地更改，否则更改将被视为处于“暂存”状态，并且在提取期间不会自动合并。幸运的是，git非常宽容，非常善于处理合并冲突。