您正在尝试为我的团队实施TFS（18名成员）。
我做了两个分支 1）主要分支 2）开发分支
我们正在使用敏捷。
所以每周都有冲刺。在每个星期四，我都会将Dev的变化合并到主分支。
每个开发人员都在处理不同的用户故事。如果他完成任务并检查所有更改（5个文件）。生成变更集（例如62）。但测试人员报告了单元测试时的错误。开发人员修复错误并签入1个文件。它产生了一个新的变更集（例如63）。
问题是，当我将用户故事的更改合并到主分支时，我感到困惑的是要移动哪个更改集。 （62,63 ....）
我所做的是比较整个项目。有时候很头疼。
有人可以提出更好的方法。或者我错过了什么？任何可以提供帮助的博客
谢谢
答案 0 :(得分：1)
如果您有一个DEV分支，这意味着您应该将整个分支和所有更改合并到MAIN（而不是挑选樱桃，这就是您所描述的内容）。
如果您希望灵活地仅合并与某些故事/错误相关的变更集，那么您应该采用不同的分支模式，例如逐个分支。
答案 1 :(得分：-1)
您需要更改构建和交付软件的方式，以便更顺利地交付。
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
您在挑选变更集时所描述的内容将持续不断地降低产品质量。
如果你实现了对完成的良好定义并让你的团队在团队中工作而不是独立工作，那么你应该在每个sprint结束时使用工作软件。就在Sprint审核之前（恰好及时）你应该使用changset作为水印合并从dev到main的所有内容。如果您的sprint中有故事尚未准备就绪，那么您应该将它们隐藏在功能标记后面并发货。
如果这听起来很难，或者某些“在这里不起作用”，或者你认为“或产品比这更复杂”，那么你可能会遭受重大的技术债务而你需要支付这笔费用直到你让产品负责人选择在每个sprint结束时发布所有内容。