什么是一些最常见的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，并且我们已经制定了一个对我们非常有效的策略。

• 硕士总是一份正在生产的东西。当代码发布后，当前分支被快速转发给主控，并添加一个标签，以便及时标记该版本，如果需要的话，我们可以获取代码。
• 开发人员可以自由地按照自己的意愿开展工作，但是对于功能分支，我们通常为每个功能分配一个分支，多个开发人员合并到该分支并共享该功能的工作。
• 当它发布候选版本时，会创建一个RC_XXX分支，并且足够长的特征分支全部合并到它中。然后测试它，并修复错误。
• 当所有事情都说完之后，RC_XXX分支就会发布到生产环境，并且在它“坚持”几天之后，我们会将其推广到掌握之中，然后基于它创建新的功能分支。

这很有效，因为针对生产的热修复很容易通过将主分支分支来创建和部署，并且开发人员可以根据需要对功能分支进行分支以引入依赖关系。

Answer 2

这个怎么样（我忽略了什么开发商有自己的机器上）：

• 每个开发者都有一个接受的补丁分支（QA提交这里），即从最后一个检查点大师基于（新每一个版本的分支）
• 每个开发者都有一个悬而未决的补丁分支他犯成持续对接受的补丁分支（持久分支）
• 一次QA是所有开发人员进行重订为大家所接受的补丁分支合并到主
• 新的QA分支被创建并且所有的开发者再次发生变形

Answer 3

“发布后，开发人员重新绑定他们的分支”：ouch ...

我不是一个Git顾问（但是），但是根据经验，开发人员应该更频繁地重新组织他们的工作（而不仅仅是“发布后”）。
否则，就像你在你的评论中提到的那样，导致大量的“git revert”（它可以工作，但应该保持一个特殊的情况而不是常见的修复）。

点对点协作是可能的，但有一点纪律，因为它requires setting up a bare repo和local protocol。