有哪些最常见的Git分支方案/提交生命周期？

Question

首先，对不起，如果这是重复，但我尝试搜索，我所能找到的只是如何在Git和诸如此类的分支。那不是我想要的那么多;我试图找出不同的人如何设置他们的Git分支以匹配他们的工作流程。

让我举个例子说明我们公司是如何做到的：

1. 开发人员在本地提交他们自己的分支
2. 开发人员将提交推送到他们的远程，其中持续构建系统检查它，另一个开发人员检查它
3. 如果审核/构建通过，则提交将合并到QA分支中（如果失败，则会在审核/构建通过之前进行更多提交）
4. 如果提交失败QA，则进行还原提交以将其取出
5. 在准备好足够的QA提交后，我们的主分支获取提交（QA分支基于它，因此不需要合并）
6. 定期分支取自主分支，用于释放“进入野外”。如果在此处发现问题，则将再次使用还原提交来删除代码
7. 发布后，开发人员将他们的分支机构重新分支到主分支（获得他们以前的提交和其他开发人员的提交）

现在，这个系统存在一些问题;我会在评论中注意到一些，但我并不是真的在寻找“请为我修复我们的系统”，我只是想看看我们可以使用的其他分支选项，以便我可以权衡各种可能性。

所以，如果你曾经在多家使用Git的公司工作过（或者更好，如果你是一位看过大量Git设置的顾问），请你分享一下：不同的公司如何设置Git分支机构（并在他们之间移动提交）以促进各个发展阶段...尽可能地尽可能地最小化烦恼？我敢肯定必须有一些共同的模式......但我不知道它们是什么。

P.S。如果您只看过一个Git设置，但您认为它很有意思，请务必发布。但是，我想将答案提供给那些提供最佳可能选项细分的人，我希望这会来自那些看过几个Git设置的人。

Answer 1

我现在一直在管理几个使用Git的团队，我们已经制定了一个对我们有效的策略。

• Master始终是完全正在制作的副本。代码发布后，当前分支会快速转发给master，并添加一个标记，以便及时标记版本，如果需要，我们可以获取代码。
• 开发人员可以自由地按照他们的分支方式工作，但是对于功能分支，我们通常为每个功能分配一个分支，并且多个开发人员在该分支中进行合并以共享该功能的工作。
• 当创建候选版本的时间时，创建RC_XXX分支，并且足够远的功能分支全部合并到其中。然后对此进行测试，并修复错误。
• 当完成所有操作后，RC_XXX分支将被发布到生产中，在它“坚持”几天后，我们将其推广到掌握，然后新的功能分支将基于它。

这非常有效，因为只需分离master就可以轻松创建和部署针对生产的热修复，并且开发人员可以根据需要分支功能分支以引入依赖关系。

Answer 2

这个怎么样（我忽略了开发人员在他们的机器上拥有的东西）：

• 每个开发人员都有一个可接受的补丁分支（此处提交QA），该分支基于最后一个主检查点（每个版本的新分支）
• 每个开发人员都有一个挂起的补丁分支，他将继续针对已接受的补丁分支（持久分支）进行重新定位
• 一旦为所有开发人员完成了QA，所有接受的补丁分支都将合并为主
• 创建新的QA分支，并且所有开发人员再次进行rebase

Answer 3

“发布后，开发人员重新分支他们的分支”：哎哟......

我还不是Git顾问，但根据经验，开发人员应该更频繁地改变他们的工作（而不仅仅是“在发布后”）。
否则，就像你在评论中提到的那样，会导致很多“git revert”（这有效，但应该保持特殊情况而不是常见修复）。

点对点协作是可能的，但在requires setting up a bare repo和local protocol中会引起一些纪律处分。