看板、生产支持、环境的 Git 合并策略

Question

我们目前正在重新评估我们的 git 合并策略。我们现有的“生产支持”项目当前的工作流程是：

1. 当您开始开发时，您可以从项目develop分支创建您的分支。
2. 当工作完成后，代码会返回pull request到develop分支。这develop是一个CICD分支，因此一旦pull request通过，所有这些更改都可以在我们的开发环境中进行测试。
3. 一旦工作经过测试并且业务团队准备好将其投入生产，它就会cherry-picked进入一个分支，然后再合并到该master分支中。

这似乎暂时有效。master然而，有时某个功能的优先级会降低，特别是如果某个功能有问题并且原始开发人员已被分配给更高优先级的任务，我们最终会遇到分支为 100+ behindAND 100+的情况ahead。这意味着我们走的时间越长，master看起来就越少develop，而且越糟糕，而且随着时间的推移，似乎合并往往会导致越来越频繁和复杂merge conflicts。这里的痛苦已经变得足够严重，我们需要更好的解决方案。

我研究了各种策略，尤其是Feature Branch策略，但我担心其中的一些部分，例如，我们如何才能有一个CICD具有这样策略的分支......每个开发人员都需要为每个开发人员提供一个新的开发环境吗？特征？对于构建在其他功能之上的功能怎么样，有没有一种好的方法来跟踪此类依赖关系？有没有其他更好的方法来管理我们的代码改动而不带来痛苦？不知道这很重要，但我们使用ASP.NET/C#.

Answer 1

您可能会考虑：

1、Master为主线的主干开发

（“ Mastermind Merge ”：重点以master作为所有开发活动的中轴，简化流程）

理由：

• 与jessehouwing的建议一致，消除develop分支简化了工作流程，并确保所有开发活动都围绕单一事实来源：分支master。
• 正如 jessehouwing 所提到的，结合看板中“承诺点”的概念，可确保合并的工作master完成并经过测试。

持续集成/持续交付：

基于主干的开发与 CI/CD 配合得很好，因为它鼓励频繁合并到master.
这意味着您的 CI/CD 管道可以配置为在将更改推送到master.

环境：

• 无需为每个开发人员提供单独的环境。尽管您可以在合并之前使用临时环境进行短期测试，但共享开发环境应该足够了。
• 开发人员直接从 中创建短期功能分支master，有效简化了分支模型。
• master这些分支一旦完成并通过了所有必要的测试，就会立即合并回来。

2. 特征标志与基于主干的开发相结合

（“ Toggle Triumph ”：使用功能标志作为抽象分支的形式，允许更灵活和适应性更强的代码库。）

理由：

纳入 jessehouwing 关于处理更改优先级并通过使用功能标志降低复杂性的观点。jessehouwing 提到，功能标志也可以被视为“抽象分支”的一种形式。

持续集成/持续交付：

无需更改代码即可从外部控制功能标志，从而使您的 CI/CD 管道保持简单。
部署可以连续进行，因为新代码可以在“关闭”状态下引入，并且不会影响生产行为。

环境：

• 同样，不需要为每个功能提供单独的环境。功能标志允许相同的代码库根据环境的不同而表现不同，从而可以使用共享的开发环境。
• 开发人员将功能标志合并到 的代码中master，从而允许打开或关闭功能。
• 正如 jessehouwing 所建议的那样，这种方法master允许隐藏或停用不完整或优先级较低的功能，直到它们准备好为止，从而使合并变得更加精简。

3. 根特征分支master

（“ Root-and-Shoot ”：倡导创建功能分支以master保持线性且干净的提交历史记录，从而更容易合并和部署）

理由：

考虑到j6t建议将功能分支扎根于master而不是develop.
这将使将这些分支合并回master并维护更简单的提交历史变得更容易。

持续集成/持续交付：

由于功能分支基于master，因此将它们集成回来很简单。
您的 CI/CD 管道可以配置为自动构建和测试这些功能分支，然后再将它们合并回master.

环境：

虽然共享开发环境就足够了，但此策略可能会受益于临时“功能环境”，以便在合并回master.
然而，这些环境并不是每个开发人员都严格必需的，但对于更大、更复杂的功能可能是有益的。

执行：

• 根据 j6t 的评论，功能分支是根据master.
• 经过彻底的测试后，这些分支可以重新合并，而master无需进行挑选，从而保持提交历史记录的干净和简单。

所有三种策略都与 CI/CD 工作流程兼容，并且不需要为每个功能分支提供单独的开发环境，尽管如果需要，可以在“Root-and-Shoot”策略中使用该选项。
CI/CD 可以配置为基于master分支或单个功能分支中的活动进行构建和测试，具体取决于所选策略。