从主干或分支释放？

Question

我们最近（过去 2 个月）开始使用 TeamCity t 进行部署。这教会了我们很多关于正确使用 SC、陷阱以及在一个拥有多个项目的团队中工作的知识。但是我们仍然不清楚如何最好地使用主干、分支和标签。

我们目前的流程是：

• 请求一个工作单元。
• 为开发人员创建了新分支。
• 在分支中完成开发后，将主干合并回分支中，以确保包含任何最近的更改。
• 此时分支已准备好进行测试，这就是我们的不确定性开始的地方！

我听说其他开发人员说我们应该只从主干发布，我确信当发布到生产环境时这是真的。但是，在分支准备好进行测试的阶段，我们应该合并回主干然后发布到我们的测试环境似乎并不合适，还是应该这样做？

我考虑过的另一种方法是创建一个名为 TEST 的分支，然后总是从那里合并并发布到测试环境，但这种方法也可能存在隐藏的缺陷。

我能否就这个话题寻求一些指导/建议？比如你是做什么的？

我不会在这篇文章中提出标签的主题，因为我知道这可能会使问题复杂化。

提前致谢 点开发

Answer 1

以下是我的建议：

1) 在 Trunk 分支上进行所有开发并将其用于测试。我假设您同时处理多个功能/错误。我会避免为每个功能创建单独的分支，除非您不断地将更改从主干合并回功能分支。

2) 一旦你准备好发布，就在此时从主干创建一个新的发布分支。将分支部署到 QA/Staging 环境进行测试。

3) 开发人员可以在创建 RELEASE 分支后开始处理新功能并开始签入对 Trunk 的更改。在测试过程中发现的任何回归问题都将首先在 RELEASE 分支中修复，然后再合并回 MAIN。

4) 对 RELEASE 分支中代码的任何更改都将被推送到 QA/Staging 以进行进一步测试。

5) 一旦发布完成，在生产中发现的任何错误都将在 RELEASE 分支中修复并热修复到 Prod 并合并回 Trunk。

我建议为每个 RELEASE 创建一个新分支，然后定期删除旧的 RELEASE 分支，而不是使用标签。

所以我的建议是始终从 RELEASE 分支发布到生产环境。由于您使用的是 teamcity，因此您还应该考虑创建持续集成构建（即每次签入时构建项目）

Answer 2

我发现，强制在一个分支上进行所有开发会迫使开发人员小心并考虑所有工作。我见过使用每个功能的分支，但我总是发现它存在问题：

• 我有很多时间玩母鸡。 “您是否已签入您的更改？”，“您是否将更改交付到主干”，“您是否一直在更新您的分支以了解更改在后备箱中”。我宁愿做实际的 CM 工作，而不是纠缠开发人员。
• 总是在最后一分钟将代码交付到主干中，这会导致合并问题。你以为你已经准备好发布了，但在发布日期前两天突然大量工作涌入了后备箱。
• 在分支上工作的一个想法是，它允许您选择要发布的内容。您可以处理功能 A、功能 B 和功能 C，然后决定是否只发布其中一个功能，其中两个他们，或者他们三个！问题是这些功能不是相互独立的，最终可能会同时出现多达 50 个或更多的分支。合并从来没有理论上那么顺利。
• 说到合并：合并是开发中最粗糙和最糟糕的方面。它充满了危险，而且大多数开发者都不擅长。

当您让所有开发人员都在一个分支上工作时，您将停止合并，因为没有什么可合并的。开发人员永远不会不知道某人的更改，因为它在分支中。开发人员将保持一致。是的，你失去了选择特征的能力，但最好在冲刺之前完成。

那么，我从主干释放？不，我从一个分支发布。总有一天，您会为下一个版本完成大部分开发工作。现在，只是修复错误，您只需要一两个开发人员来解决测试中发现的错误。

这是您创建发布分支的时候。您的大多数开发人员将继续在 trunk（或任何您称其为的名称）上工作，并且在发布中发现的错误已在分支上修复。当您发布时，您标记并发布分支。如果您需要制作一个中间版本来修复错误，您可以使用相同的分支。

例如：我们为 1.2 版本开发主干。当我们完成功能的工作时，我将创建一个 Release 1.2 分支。现在，版本 1.2 的所有工作都在分支上，我未来版本（可能是 1.3）的工作将继续在主干上。当我们完成 1.2 版的工作时，我们标记分支并从分支中发布。

迟早需要修复 1.2 版中发现的错误。主干已经是1.3了。但是，我们只会在 1.2 分支上进行错误修复，然后从那里进行 1.2.1。

有时我需要一个功能分支。例如，我有一个功能需要一段时间才能完成，并在未来实施。在这种情况下，我将创建一个功能分支，并允许开发人员处理它。但是，开发人员必须不断将父分支合并到该功能分支中以跟上所有更改。并且，当他们完成该功能的工作时，我们将父分支合并到功能分支，测试并确保一切正常，然后将功能分支合并到父分支，并确保父分支与功能分支匹配。

所以，回顾一下：

• 我们作为一个团队一起在 trunk 上完成所有工作。
• 当我们到达某个神奇的神秘点（功能完成或最后一个 sprint）时，我们会分支到发布分支。
• 为某些未来版本在主干上继续工作，而发布分支用于下一个版本。
• 发布工作完成后，我们从分支发布并标记。
• 我们不是教条主义的。有时我们会进行功能分支。也许，如果你有一个非常小的开发团队，你可能不会在发布时分支。您只需从主干发布，如果您需要制作补丁，您可以在发布点分支并制作补丁。

重点是我们尽量避免不必要的分支，并尽量减少合并。我不在乎合并算法有多棒，或者合并的自动化程度如何，合并是一个草率的过程，很少有人知道如何正确地完成它（或者至少努力正确地完成它）。

创建一个分支就像创建一个孩子：创建一个分支后，您必须观察并照顾它，确保它不会出现问题。