什么是一些常见的Git分支方案/提交生命周期？

Question

首先，如果这是一个重复的问题，我很抱歉，但我尝试过搜索，但我只能找到关于如何在Git中创建分支等内容。那不是我想要的，我正在尝试弄清楚不同的人们如何设置他们的Git分支以匹配他们的工作流程。

让我给你举个例子，我们公司是这样做的：

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

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

因此，如果您曾在使用Git的多个公司工作过（或者更好的是，如果您是某种类型的顾问，已经看到了大量的Git设置），那么请分享：不同的公司如何设置Git分支（并在它们之间移动提交）以促进开发的各个阶段...同时尽可能地减少麻烦？我相信一定有一些常见的模式...但我不知道它们是什么。

附言：如果您只看过一个Git设置，但认为它很有趣，请发帖。然而，我希望将答案授予提供可能选项的最佳分解的人，并且我希望这将来自于看到过多个Git设置的人。

- machineghost

---

我提到了我们的系统存在问题。其中一个例子是变基：Git有很多很酷的变基工具，但我们只能在最开始使用它(提交到QA之前)，或者在最后使用它(将提交加入到开发者分支中);如果我们想要在中间任何时候重新排列或删除提交，我们必须使用还原提交。这导致了另一个问题，也就是我们的Git历史记录：由于我们所做的所有合并提交和还原提交，我们会得到大量的日志垃圾。这个系统的另一个问题是，提交不能很容易地在开发者之间共享（用于对等编程）... - machineghost

...还有其他问题，但正如我所说的，我并不寻求具体的解决方案，只是想了解可能的替代方案。 - machineghost

请将此内容添加到主贴中，而不是评论中。 - Šimon Tóth

我故意试图将那些评论与主要答案分开，因为它们只是脚注；问题是“Git社区中有哪些常见情况”，而不是“我该如何修复我的Git设置”。 - machineghost

Answer 1

我现在管理着几个使用Git的团队，我们已经发展出一种对我们非常有效的策略。

• Master分支始终是正在生产环境中运行的确切代码副本。当发布代码时，当前分支将被快速推进到master分支，并添加一个标记以便于标记该发布时间，如果需要，我们可以获取代码。
• 开发人员可以随意使用自己的分支来工作，但对于功能分支，我们通常为每个功能创建一个分支，并允许多个开发人员合并到该分支中以共享在该功能上的工作。
• 当需要发布候选版本时，将创建一个RC_XXX分支，并将已经完成足够的功能分支都合并到其中。然后进行测试，并从中分支出进行错误修复。
• 最后，RC_XXX分支被发布到生产环境，然后在几天内“附着”，然后我们将其提升为master分支，然后新的功能分支基于它创建。

这样做非常好，因为只需从master创建分支即可轻松创建和部署针对生产环境的热补丁，而开发人员可以针对功能分支创建分支以拉取必要的依赖项。

- Chris Kooken

---

我选择了这个答案，因为示例来自Git的几个团队，而且其他答案似乎都没有了。 不过，如果有其他人有更多的例子，我仍然很想看到它们。 这种特定的策略对于我们的QA测试不起作用：我们的QA团队经常在不同开发者的工作之间进行切换，然后每隔X天（X因团队而异），我们会发布从上一个发布以来通过QA的任何内容。 如果某些内容未通过QA，则由QA负责将其删除。我不知道其他人是否也有相同的风格，但即使您没有，我仍然赞赏其他的例子。 - machineghost

Answer 2

这个方案是否可行（忽略开发者本地机器上的情况）:

• 每个开发者有一个已接受的补丁分支（QA在此提交），该分支基于最新的主干检查点（每个发布创建新分支）
• 每个开发者有一个待处理的补丁分支，将其连续地重新基于已接受的补丁分支（持久分支）
• 一旦所有开发者完成QA，所有已接受的补丁分支合并到主干
• 创建新的QA分支，所有开发者再次重新基于新的QA分支

- Šimon Tóth

---

比我的回答更准确。+1 - VonC

这是一个有趣的选择，谢谢（不过我还在寻找其他选项 :-) ）。 - machineghost

Answer 3

“发布之后，开发人员需要将它们的分支进行变基操作”: 噢哦...

我虽然还不是Git顾问，但通过经验，开发者应该更频繁地进行变基操作（而不仅仅是“发布之后”）。 否则，如您在评论中提到的那样，这会导致大量的“ git revert ”（这确实有效，但应该作为例外而不是常见的修复方法）。

点对点协作是可能的，但需要一定的纪律性，因为它 需要设置裸仓库 和 本地协议。

- VonC

---

我们每周发布一次，所以情况并不像听起来那么糟糕 :-) 但我仍然试图专注于更广泛的Git生态系统，以及每个人设置他们的Git分支/仓库的不同方式，而不是专门针对我的公司（到目前为止，我观察到有关Git该怎么做没有“正确”答案，只有适合X的答案，而且由于我甚至不知道应该考虑哪些可能的X，专注于“解决”我们的设置有点过早）。 - machineghost