Git 分支策略思路及git 流程定制

Question

我最近开始使用 Git，最近我和我的团队已经同意以下工作流程。 我们不使用 CI/CD，也没有未来的计划。 我们有 3 个测试环境：

1. 开发测试
2. UAT/预产品
3. 生产

目前我们正在遵循功能分支工作流程，我们的分支结构如下：

master -> integration

master -> devtest

master -> preprod

我们是一个由 6 名开发人员组成的团队，在任何时候都需要在开发测试和预生产环境中提供不同的功能。

所有功能都从 master 中签出，开发完成后，对于第一轮测试，我们将功能合并到 devtest 分支中。

一旦测试人员批准了这一点，功能就会合并到 UAT 的 preprod 分支中。 获得批准后，我们将此更改合并到集成分支，并最终在部署后合并到主分支。 在将集成合并到 master 后也创建一个标签。

Q1。 由于我们不是高级 git 用户，我想对这种分支策略发表意见，如果有更好的选择，这种方法的缺陷或改进。

Q2。 我目前正在研究git flow和git flow avh ，但它们都不支持我的分支策略。 有没有办法根据我的需要配置这些命令？

先感谢您。

Answer 1

尽管您已经在问题中提到了它，但我建议您坚持使用 Atlassian 概述的 vanilla Gitflow Workflow 。

正如您所描述的，通常不需要为每个环境都有一个单独的分支。 此策略将增加不必要的分支开销，而不会为您的开发团队带来额外价值。

将master作为您对 prod 内容的快照非常棒。 如果需要，您可以从那里分拆修补程序分支。

我会维护一个develop分支（关闭master ），您将其用作所有功能分支的父级。 当您添加了足够数量的功能进行develop并准备好发布一个版本时，然后创建一个发布分支。 您可以通过您的环境推广该发布分支并根据需要进行更改。

一旦你准备好生产，将你的发布分支合并到master并标记它。 如果您在分支develop分支后对发布分支进行了其他更改，您也需要将这些更改合并到develop中。

当您开始设置 CI/CD 时，我将使用develop分支进行 CI 构建并发布到您的开发环境（或任何您称之为最低层环境的环境）。 然后，您可以获得有关您的更改的持续、即时的反馈。 然后，您可以使用发布分支将发布自动化驱动到您的其他更高环境。

更新：新场景

你知道你明天要削减一个发布分支，而今天早上有五个开发人员已经完成了他们的特性分支。 您有很多选项可以将它们“门”合并到develop中。

你可以在你的站立会议或计划会议上讨论，“嘿——我已经完成了我在 XYZ 上的工作，我应该将它合并到develop中吗？” 这对你的技术主管 PO 来说是一个很好的机会，无论他说“不，我们计划明天删减一个版本，我们不希望你的更改包括在内”。

您还可以锁定develop分支，只允许通过合并/拉取请求进行合并。 当一个功能分支的合并请求出现时，您会决定：是现在包含它还是应该推迟到下一个版本？

因此，在您削减发布之前，可能只有五个功能分支中的三个被合并到develop中。 太好了——这就是你想要的。

特征分支不会自发消失。 虽然您应该尽快将它们合并到develop中，但您不必立即将它们合并。 如果你需要推迟，你可以推迟。

更新：地址评论

如果您必须挑选特性分支以提升到您的 UAT 环境，那么您可以尝试使用您的发布分支来执行此操作。 您的五个开发人员都完成了他们的功能开发并将他们的更改合并到develop分支中（不要像往常一样删除功能分支）。 与“已批准”的特性相关联的特性分支可以合并到一个新的发布分支，该分支是从master分支出来的。 该发布分支已准备好用于 UAT（或任何其他合适的环境）。

我强烈反对这种策略。 这将是凌乱且完全麻烦的。

与其在develop和发布分支之间进行微管理功能分支（如上所述），不如在开始开发之前让您的功能“获得批准”。 一旦特性成功合并到develop中（使用合并/拉取请求进行代码/质量审查过程），它们相关的特性分支就可以被删除。 一旦develop处于足够好的 state 以剪切发布分支，分叉develop并创建一个新的发布分支，该分支将在您的许多环境中推广。

如果一个特性分支被合并到develop中，但业务已经改变主意并希望删除该特性，那么创建另一个特性分支来删除它。 如果一个特性分支被合并到develop中，但开发团队认为该分支的更改会引入错误或不合理地增加你的技术债务，那么重新评估你的代码审查过程并创建一个新的特性分支来删除那些不需要的更改。 旨在将develop分支更新为下一个版本。 准备好后，剪下一个版本。

如果一个特性分支不应该被合并到develop中（因为批准或任何其他原因），那么不要合并它。

功能切换（不通过源代码管理）

有些开发团队努力通过某种配置机制使他们的新功能可以切换。 这会引入额外的编程开销，因为您必须以一种方式来启用/禁用新功能。 现在您有更多的代码需要编写、测试和维护。 您还必须对出现的任何跨功能依赖项进行微观管理。 您可以构建功能 C并了解它将附带启用的功能 A ，但企业决定在下一个版本中禁用功能 A。 go 会出现什么问题？

虽然，这种技术允许团队在将新功能添加到代码库时发布它们，而无需为最终用户启用它们。 这意味着在剪切发布分支时，您的“未批准”功能仍然可以包含在功能的 rest 中，但它们将被禁用。 如果可能的话，我会尽量避免这样做，因为它会变得过于复杂。 但是，如果您的产品所有者要求这种灵活性，这可能是您决定采用的策略。 不过，一定要提醒他们这是一种代价高昂的策略。

如果您对此感兴趣，请阅读有关功能切换的更多信息。 Martin Fowler 写了一篇非常好的文章。