批准后,在TFS中检查代码审核中的代码

时间:2017-09-12 19:03:18

标签: tfs tfs-code-review

我想在代码审核批准后签入代码。我遇到了关于创建代码审核和签入的stack,但我的问题有点不同。

我的问题是我想创建一个代码审查;但是,在批准之前我不想检查代码。这限制了我无法通过删除相关工作项来启动另一个代码审查。我想要做的是创建代码审查并从团队资源管理器中的代码审查选项卡中检入

TFS Code Review

这可能吗?它与creating a code review after the check in的原理相同,但是使用代码审核和签入。我不想进行挂起更改并在那里签到,因为我可能已删除相关项目。但我确实希望办理登机手续与我的代码审查相关联。

2 个答案:

答案 0 :(得分:2)

不幸的是,没有“正确”的方法来做你想要做的事情。您可以将您的工作目录放在共享驱动器上,并在您准备好让他们开始审核过程时通知您的审核人员,但是通过不在TFS中正式记录每个开发/审核迭代来实现问责制。这意味着您应该检查您的工作并让审核人员完成他们的工作,然后继续以这种方式进行审核人员要求的任何更改,签入并获得另一个代码审查。

为了完整起见,我也会从我的评论中提及我的建议。

我的建议是创建一个独立的,短命的开发分支,您将在其中进行开发并检查代码。然后,一旦开发和审查完成到满意,该分支就可以合并备份并销毁。这提供了更清洁和更安全的方法。 1)它减少了TFS内历史的混乱。 2)它可以防止多个不必要的自动构建/测试等等被触发。

在您的评论中,您建议这会更改“分支方法的结构”。我不知道这样做会如何改变任何重要的方式。您的合并将像您的最终开发签到一样,但此时所有评论都已完成,您正在执行单一,干净的登记。它仍将包含您的所有签到和审核信息,但是,您将拥有一个折叠的节点,其中包含为该特定任务完成的每一件事。而不是一个混乱的签到链。

我会咨询您的经理,您的代码审核人员和/或您负责TFS以及创建/维护TFS政策的任何人。这种方法实际上并没有改变任何过程的其余部分。您可以简单地将开发周期抽象为自包含环境。第二次执行合并时,您现在就可以恢复正常流程了。

答案 1 :(得分:2)

好的,所以出于文档目的。我没有完全理解TFS允许我做的搁架。阅读Shelve and Unshelve Pending Changes后,对我来说更有意义。我可以搁置我正在处理的工作,取消我已经完成代码审查的代码,然后检查该代码。这样我就可以创建代码审查并继续工作,直到批准代码审查。一旦获得批准,我就可以取消更改并将其签入。