如何为多序列故事（Git流）设置分支策略？

Question

我们正在从TFS迁移到Git（Azure DevOps），对于以下情况，我不清楚最佳策略：

[Sprint中有两个故事。

1. PBI-1：添加功能XYZ
2. PBI-2：扩展功能XYZ

注意：

• 每个PBI都将相当“庞大”，即涉及多个Commit，并且可能涉及多个开发人员
• PBI-2显然依赖于PBI-1，并且只有在PBI-1完成后才能启动

也请注意：

• 我们在'develop'分支上有一项政策，即所有代码都必须先经过批准者的批准，然后才能合并到其中
• [合并为'develop'时，我们进行了“南瓜合并”，然后自动删除了源分支

好的，从我的阅读中看来，每个PBI都应该位于其自己的“功能分支”（从“开发”分支创建）中。既然如此，那么我猜：

在Sprint的开始，我们从'develop'创建了一个新的功能分支，称为“ Feature / Add-XYZ”。

然后，多个开发人员将开始进行此工作，并从'develop'，常规的Commits和Pushs到服务器版本的常规日常重新基准流程（note：有关不使用重新基准的原因，请参阅下面的评论） “ Feature / Add-XYZ”分支（在DevOps上）。

当完成PBI-1上的所有工作并将所有代码推送到服务器时，将创建一个Pull Request并将其发送给批准者。

但是，批准人非常忙，可能几天都没有收到请求请求；我们不希望这成为障碍，因此团队应该如何着手考虑下一个PBI：

• PBI-2取决于位于分支“功能/添加-XYZ”中的代码
• 批准程序完成后，分支“功能/添加-XYZ”将被删除

我的猜测是我会：

1. 从“主”创建一个新分支，称为“ Feature / Extend-XYZ”（由于它仍在分支“ Feature / Add-XYZ”中，因此不包含与XYZ相关的任何代码）
2. 然后，我需要将相关代码从分支“ Feature / Add-XYZ”复制到“ Feature / Extend-XYZ”。

如果这是正确的方法，那么建议您完成步骤2的方法是什么？它是一个简单的“合并自”吗？

Answer 1

我的猜测是我会：

1. 从“主”创建一个新分支，称为“ Feature / Extend-XYZ”（由于它仍在分支“ Feature / Add-XYZ”中，因此不包含与XYZ相关的任何代码）
2. 然后，我需要将相关代码从分支“ Feature / Add-XYZ”复制到“ Feature / Extend-XYZ”。

不，您会从不要将代码从一个分支复制到另一个分支。准备好开始使用第二个功能时，您只需从第二个分支中分支出第二个分支即可。如果随着时间的流逝，对第一个分支进行了新的添加，则可以将该分支合并到第二个分支中。

回想一下为什么...

• PBI-2取决于位于分支“功能/添加-XYZ”中的代码
• 批准程序完成后，分支“功能/添加-XYZ”将被删除

删除无所谓。删除分支不会影响分支的分支。

最后的注释：

具有通常的日常重新基准流量

您不应该在分支机构中建立基础，该分支机构中有许多人正在积极工作。如果一个人这样做，那么分支机构的历史将被其他所有人打破。而是将develop合并到您的功能分支中。