我们开始使用功能分支,并且我们希望设置一个签入策略,该策略仅允许在具有关联的代码审查时签入基线.
2012年新的代码审查工作流程非常好,因为您可以轻松地与开发人员和其他审阅者进行交互,并直接评论代码行.然而,似乎MS没有充分考虑用例,因为我们很容易遇到以下问题:
开发人员定期进行功能分支登记/搁置和前向整合.
当她想要集成该功能时,她会合并回基线并请求对这些待处理的更改进行审核.
审稿人发表了几条评论,现在她必须改变一些代码.她在哪里这样做？
选项1:返回分支,编辑代码并签入分支中的更改.撤消第一次合并的挂起更改.合并并再次请求审核.重复,直到没有更多评论.签入合并.这不是很好,因为所有评论评论都在合并的待定更改中,并且她必须在她没有直接看到评论的分支上工作.
选项2:直接对合并的挂起更改进行编辑.再次申请审核.重复,直到没有更多评论.签入合并.如果她想继续在分支机构工作,她将不得不进行前向整合,因为审查的变化不存在.
无论哪种方式,第二次审查总是非常烦人,因为您无法只看到第一次和第二次审核之间的变化,因为您总是在与基线进行区分.
我在这里错过了什么吗？是否有其他选项可以审核审核中的更改？有没有人有更好的功能分支和代码审查方式？
新:使用VS和TFS2013,仍然没有改进:(