我想在代码审查获得批准后 checkin 代码。我遇到了这个 stack关于创建代码审查和 checkin ，但我的问题有点不同。
我的问题是我想创建一个代码审查；但是，在代码获得批准之前，我不想 checkin 代码。这限制了我通过删除相关工作项来开始另一个代码审查。我想做的是创建代码审查并从团队资源管理器中的代码审查选项卡 checkin
那可能吗？原理与creating a code review after the check in相同，但有代码审查和 checkin 。我不想去挂起的更改并在那里 checkin ，因为我可能已经删除了相关项目。但我确实希望 checkin 与我的代码审查相关联。
最佳答案
不幸的是，没有“正确”的方式来做你想做的事情。您可以将您的工作目录放在共享驱动器上，并在您准备好让他们开始他们的审查过程时通知您的审查者，但由于没有在 TFS 中正式记录每个开发/审查迭代，这会回避问责制。这意味着您应该检查您的工作并让审阅者完成他们的工作，然后继续以这种方式进行审阅者要求的任何更改，检查并进行另一次代码审查。
为完整起见，我也会在此处提及我的评论中的建议。
我的建议是创建一个独立的、短期的开发分支，您将在其中进行开发并审查您的代码。然后，一旦开发和审查完成到满意，该分支就可以合并备份和销毁。这提供了一种更清洁、更安全的方法。 1) 它减少了 TFS 中历史记录的困惑。 2)它可以防止触发多个不必要的自动化构建/测试/等...。
在您的评论中，您建议这会改变“分支方法的结构”。我看不出这样做会如何以任何重要的方式改变任何事情。您的合并就像您最终的开发 checkin 一样，只是此时所有审查都已完成，并且您正在执行单一、干净的 checkin 。它仍将包含您的所有签到和审查信息，但是，您将拥有一个折叠的节点，其中包含为该特定任务完成的每一件事，而不是杂乱的签到链。
我会与您的经理、您的代码审查员和/或您负责 TFS 和创建/维护您的 TFS 策略的任何人核实。这种方法实际上不会改变其余流程的工作方式。您可以简单地将您的开发周期抽象为一个独立的环境。当您执行合并时，您会立即回到正常流程，就像现在一样。
关于tfs - 批准后从 TFS 中的代码审查中 checkin 代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46183677/