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