我想在代码审查获得批准后签入代码。我遇到了这个关于创建代码审查和签入的堆栈，但我的问题有点不同。
我的问题是我想创建一个代码审查；但是，在代码获得批准之前，我不想签入代码。这限制了我能够通过删除相关工作项来开始另一次代码审查。我想做的是创建代码审查并从团队资源管理器中的代码审查选项卡签入
那可能吗？这与签入后创建代码审查的原理相同，但需要进行代码审查和签入。我不想去挂起的更改并在那里签入，因为我可能已经删除了相关项目。但我确实希望签到与我的代码审查相关联。
问问题
6087 次
2 回答
3
不幸的是，没有“正确”的方式来做你想做的事情。您可以将您的工作目录放在共享驱动器上，并在您准备好让他们开始他们的审查过程时通知您的审查者，但这会通过没有将每个开发/审查迭代正式记录在 TFS 中来回避责任。这意味着您应该签入您的工作并让审阅者完成他们的工作，然后继续以这种方式进行审阅者要求的任何更改，签入并获得另一次代码审查。
为了完整起见，我也会从我的评论中提到我的建议。
我的建议是创建一个独立的、短暂的开发分支，您将在其中进行开发并审查您的代码。然后，一旦开发和审查完成并满意，该分支就可以合并备份并销毁。这提供了一种更清洁、更安全的方法。1) 它减少了 TFS 内历史的混乱。2）它可以防止触发多个不必要的自动构建/测试/等...。
在您的评论中，您建议这会改变“分支方法的结构”。我看不出这样做会以任何重要的方式改变任何事情。您的合并就像您最终的开发签入一样，只是此时所有审核都已完成，并且您正在执行一个单一的、干净的签入。它仍将包含您的所有签到和审核信息，但是您将拥有一个折叠的节点，而不是杂乱的签到链，其中包含为该特定任务完成的每一件事。
我会与您的经理、您的代码审查员和/或您负责 TFS 和创建/维护您的 TFS 政策的任何人核实。这种方法实际上并没有改变您流程其余部分的工作方式。您只需将开发周期抽象为一个独立的环境。在您执行合并的那一刻，您将立即回到您现在拥有的正常流程中。
于 2017-09-12T20:41:06.497 回答
3
好的，因此出于文档目的。我不完全理解 TFS 允许我做的搁置。在阅读了Shelve 和 Unshelve Pending Changes之后，这对我来说更有意义。我可以搁置我正在处理的工作，取消搁置我已经完成代码审查的代码，然后签入该代码。这样我就可以创建一个代码审查并继续工作，直到该代码审查获得批准。一旦获得批准，我就可以取消搁置更改并将其签入。
于 2017-09-13T16:30:28.470 回答