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