如何设置多顺序故事的分支策略（Git Flow）？
How to set up the branching strategy for multiple-sequential stories (Git Flow)?
我们正在从 TFS 迁移到 Git (Azure DevOps)，我不清楚以下场景的最佳策略：
我们在 Sprint 中有两个故事。
- PBI-1：添加功能 XYZ
- PBI-2：扩展功能 XYZ
注：
- 每个 PBI 都会相当 "large"，即涉及多个 Commit 并且可能涉及多个开发人员
- PBI-2明显依赖于PBI-1，PBI-1完成后才能启动
另请注意：
- 我们的 'develop' 分支有一项政策，即所有代码在合并到
之前必须得到审批者的批准
- 当合并到 'develop' 时，我们做一个 "squash merge" 然后源分支被自动删除
好吧，据我所读，在我看来，每个 PBI 都应该独立 "Feature Branch"（从 "develop" 分支创建）。既然如此，那我猜：
在 Sprint 开始时，我们将在 'develop' 的基础上创建一个名为 "Feature/Add-XYZ" 的新功能分支。
然后多个开发人员将开始研究这个，按照通常的日常流程进行重新设置（注意：请参阅下面关于为什么不使用重新设置的评论）来自'develop'，定期提交并推送到分支的服务器版本 "Feature/Add-XYZ"（在 DevOps 上）。
当 PBI-1 上的所有工作完成并将所有代码推送到服务器后，将创建一个合并请求并发送给审批人。
但是，Approver 很忙，可能几天都赶不上 Pull Request；我们不希望这成为一个障碍，所以团队应该如何开始下一个 PBI，牢记：
- PBI-2 依赖于分支中的代码 "Feature/Add-XYZ"
- 审批流程完成后，分支 "Feature/Add-XYZ" 将被删除
我猜我会：
- 从 "master" 创建一个名为 "Feature/Extend-XYZ" 的新分支（这将不包含任何与 XYZ 相关的代码，因为它仍在分支 "Feature/Add-XYZ" 中）
- 然后我需要 "copy" 从分支 "Feature/Add-XYZ" 到 "Feature/Extend-XYZ" 的相关代码。
如果这是正确的方法，那么实现步骤 2 的推荐方法是什么？是不是很简单"Merge From"?
My guess is that I'd:
- Create a new branch off of "master" called "Feature/Extend-XYZ" (this won't contain any code related to XYZ as that is still in the branch "Feature/Add-XYZ")
- I would then need to "copy" the relevant code from the branch "Feature/Add-XYZ" to "Feature/Extend-XYZ".
不，您永远不会想要将代码从一个分支复制到另一个分支。一旦您准备好开始处理第二个功能，您只需从第一个分支中分支出第二个分支。如果随着时间的推移，对第一个分支进行了任何新添加，您将将该分支合并到第二个分支中。
回到为什么...
- PBI-2 is dependant on code sitting in the branch "Feature/Add-XYZ"
- The branch "Feature/Add-XYZ" will be deleted as soon as the Approval Process is complete
删除无所谓。删除一个分支不会影响从它分支出来的分支。
最后一点：
with the usual flow of daily re-basing
你不应该对一个有多个人积极工作的分支进行变基。如果一个人这样做，分支的历史将为其他人打破。相反，将 develop 合并到您的功能分支中。
我们正在从 TFS 迁移到 Git (Azure DevOps)，我不清楚以下场景的最佳策略：
我们在 Sprint 中有两个故事。
- PBI-1：添加功能 XYZ
- PBI-2：扩展功能 XYZ
注：
- 每个 PBI 都会相当 "large"，即涉及多个 Commit 并且可能涉及多个开发人员
- PBI-2明显依赖于PBI-1，PBI-1完成后才能启动
另请注意：
- 我们的 'develop' 分支有一项政策，即所有代码在合并到 之前必须得到审批者的批准
- 当合并到 'develop' 时，我们做一个 "squash merge" 然后源分支被自动删除
好吧，据我所读，在我看来，每个 PBI 都应该独立 "Feature Branch"（从 "develop" 分支创建）。既然如此，那我猜：
在 Sprint 开始时，我们将在 'develop' 的基础上创建一个名为 "Feature/Add-XYZ" 的新功能分支。
然后多个开发人员将开始研究这个，按照通常的日常流程进行重新设置（注意：请参阅下面关于为什么不使用重新设置的评论）来自'develop'，定期提交并推送到分支的服务器版本 "Feature/Add-XYZ"（在 DevOps 上）。
当 PBI-1 上的所有工作完成并将所有代码推送到服务器后，将创建一个合并请求并发送给审批人。
但是，Approver 很忙，可能几天都赶不上 Pull Request；我们不希望这成为一个障碍，所以团队应该如何开始下一个 PBI，牢记：
- PBI-2 依赖于分支中的代码 "Feature/Add-XYZ"
- 审批流程完成后，分支 "Feature/Add-XYZ" 将被删除
我猜我会：
- 从 "master" 创建一个名为 "Feature/Extend-XYZ" 的新分支（这将不包含任何与 XYZ 相关的代码，因为它仍在分支 "Feature/Add-XYZ" 中）
- 然后我需要 "copy" 从分支 "Feature/Add-XYZ" 到 "Feature/Extend-XYZ" 的相关代码。
如果这是正确的方法，那么实现步骤 2 的推荐方法是什么？是不是很简单"Merge From"?
My guess is that I'd:
- Create a new branch off of "master" called "Feature/Extend-XYZ" (this won't contain any code related to XYZ as that is still in the branch "Feature/Add-XYZ")
- I would then need to "copy" the relevant code from the branch "Feature/Add-XYZ" to "Feature/Extend-XYZ".
不，您永远不会想要将代码从一个分支复制到另一个分支。一旦您准备好开始处理第二个功能，您只需从第一个分支中分支出第二个分支。如果随着时间的推移，对第一个分支进行了任何新添加，您将将该分支合并到第二个分支中。
回到为什么...
- PBI-2 is dependant on code sitting in the branch "Feature/Add-XYZ"
- The branch "Feature/Add-XYZ" will be deleted as soon as the Approval Process is complete
删除无所谓。删除一个分支不会影响从它分支出来的分支。
最后一点：
with the usual flow of daily re-basing
你不应该对一个有多个人积极工作的分支进行变基。如果一个人这样做，分支的历史将为其他人打破。相反，将 develop 合并到您的功能分支中。