我们如何设置Subversion政策，以便我们可以轻松地退出＆＃34;一个值得改变的整个故事，同时保持持续的整合？
在我的营业地点，我们将Scrum带到我们没有流程的地方/＆＃34;牛仔编码＆＃34;之前。这很有趣（Dwarf Fortress定义），但不是这个问题的重点。
在Scrum中，我们有可能让产品所有者有权说“不”＃34;完成一个故事，或者可能没有完成工作＆＃34;在短跑期间的故事。我们的想法是，如果某些事情没有完成，那么它就不会被部署。内部存在分歧 - 有些人说我们应该部署一半完成的东西＆＃34;捆绑＆＃34;所以它无法使用，但我强烈不同意（完全是另一个话题）。
通过持续集成，鼓励开发人员经常提交以尽早识别集成/回归问题。对我们来说，这意味着subversion提交，主要是发布分支模式，虽然这是灵活的。
如果我们不断致力于任何分支，请将其称为sprint分支，当我们（很少！）到达冲刺结束并且有一个无法部署的故事时会发生什么？我需要＆＃34; unmerge＆＃34;从部署分支支持该故事的任何更改。是否存在分支策略/提交策略，使其相对可行，没有大规模的手动交互？我应该担心吗？
答案 0 :(得分：1)
我认为没有任何简单的解决方案。一旦你“取消/取消”你的更改，这可能很困难，你必须重新测试一切。如果您最终遇到无法投入生产的分支，那么更好的策略是部署一个已准备好的旧版本。然后可以在准备好后部署新分支。