我检查了一个我想要工作的git项目。我没有推送权限，所以我将向上游维护者提交补丁。我想创建自己的分支，并与该分支上的其他几个人合作。工作完成后，我想将我的分支重新绑定到主项目的当前负责人，并向上游维护者发送补丁。问题是：如何在一个分支机构工作的一组人之间组织协作？
目前我使用以下设置：
我认为这是一个很好的设置但是我意识到如果我决定将我的分支从上游转移到当前主设备上，那么一切都会破裂。如果我将重新分支的分支推送到我的本地服务器，它将最终成为其他人的灾难，所以显然这不是一个正确的设置。我和我的朋友讨论了这个问题，他指出问题是由于我自己的本地服务器作为所有开发人员的中央服务器而引起的，好像它是一个subversion存储库。因此，虽然我认为我们已经意识到问题的根源，但我们没有提出一种正确的方法来组织我们的git工作流程。应该怎么做？
答案 0 :(得分：1)
你的每个工作人员应该为他们的每个小迭代创建微分支[aka特征分支]（从你的主分支;你应该），他们可以随时推送到你的服务器，让他们被看到。当每个微迭代完成时，他们（和你）会在主分支之上重新定义迭代，看它是否仍在工作并准备好与主分支集成。
这里有一场竞赛，让迭代变得短小，以便它们“正常工作”并且可以接受，并合并或快速转发到您的主分支。在某些情况下，不同的迭代将进行交互，并且相应的开发人员可以使用推/拉微分支进行协作以避免内部攻击; - ）
如果开发中有很多交叉运行功能，那么你可以使用类似于Git维护者使用的工作流程（git help workflows），Master＆lt; - Next＆lt; - pu（潜在更新） ＆lt; - 贡献者分支，pu在每个周期后重绕，贡献者拉出重新缠绕分支的新视图，看看他们的变化如何适应更大的整体。
补丁提交
一旦你在'main'分支中完成了一项工作，你应该再次获取/拉取上游主人（以及他们可能拥有的任何候选版本），并在他们之上重新定义你的更改，以确保它是最新的。
现在，您将使用git format-patch从您的分支准备一个补丁系列，很可能已经准备了一封求职信来介绍该系列。然后使用git send-email发送它们。虽然通过发送给自己，并查找上游项目提供的任何说明，但值得练习。例如Git's SubmittingPatches。