我有一个道德困境，在我的公司内，我们的整个产品套件都在主分支中，项目将从主（主干）分支分支出来。我有一个问题，即要交付的 sprint（长达 8 周）已被延迟，无法部署 2 周，但开发需要继续到下一个 sprint。
问题是，如果 sprint 1 存在需要修复的 bug，并且在现有分支上继续开发，那么 bug 修复和 sprint 2 的部分内容将混合在一起，使得发布 sprint 1 变得非常困难。
另一方面，如果我们从现有分支创建一个新分支，我们会丢失所有任务和错误，等等。
有没有办法让代码分支共享一个团队项目或者这很傻？
你会如何处理这种情况？有什么我想念的吗？
如果您在每个 sprint 中都分支到一个新的团队项目，那么您做错了。一个产品的所有分支都应该存在于同一个团队项目中。
冲刺应该与迭代而不是团队项目保持一致，这样您就可以自由地将任何工作项从一个冲刺重新分配到另一个冲刺，而不会出现问题。
如果错误很严重，则在 sprint 1 分支中修复它们并将它们合并到 sprint 2 中。这样您就可以在没有 sprint 2 代码的情况下发布它们。无论这是您最初的 sprint 1 版本的一部分还是将来的版本。
如果错误不是很严重，那么您可以在 sprint 2 分支中修复它并发布带有错误的 sprint 1。
没有理由 sprint 和分支需要 1 对 1 排列，如果你只每 3 个 sprint 发布一次，那么你也可以很容易地摆脱每 3 个 sprint 的分支。哎呀，如果您擅长发布管理并且确切地知道发布了哪些变更集，如果您需要修改 sprint 的结果，您甚至可以在发布几周后进行分支。
如果你想认真对待持续部署，那么你需要开始考虑拥有一个主干分支和特性分支，特性只有在它们完成后才会合并回主干。每个 sprint 可能有多个功能分支。或者查看功能切换，这意味着您可以部署新代码，但将其关闭，这样用户就不会注意到任何事情。