我正在与一个团队合作进行一个项目，我们会尽早并经常进行检查。个体签入已完成，以使开发人员满意地进行更改(包括可能的情况下进行测试)，但有时工作方向会稍有更改，并且先前的提交需要还原并以其他方式进行。或者，在以后的提交中填写存根代码。

当需要进行代码审查时，会有一系列的提交都标记有相同的错误跟踪ID号。很容易获得此类更改的列表。当审阅者一目了然地查看更改时，有时会有一个提交A被同一审阅的一部分撤消或者被后来的提交B修改。这会使审核变得更加困难。

如果在更改期间只有一个开发人员在处理文件，则很容易在文件的原始状态和文件的最终状态之间进行区分。当另一个开发人员恰巧在同一文件甚至同一功能中进行了不相关的更改时，就会出现问题。

我们如何处理这种情况？在给定一系列补丁程序的情况下，是否有工具可以在道德上等同于第一个和最后一个版本之间的区别，但仅包括这些补丁程序的子集？

想一想，我可以在git之前从第一个相关更改开始创建一个临时分支，然后挑选与该评论相关的更改。希望不会有太多需要解决的冲突(如果有的话，无论如何应该对整个批次进行一次审查)。还有其他想法吗？

更多信息：这恰好是一个大型旧系统，其中单个更改可能涉及多个文件。这些文件太大而又杂乱无章，太大了，以致于只能检查最终产品而没有指出可能发生了什么变化。

解决方案

回答

我认为我们应该分支机构进行更改。在这里查看我的帖子。

回答

嗯，只看文件的最后状态。

(为每个更改分配的费用是PITA。请勿这样做。)

回答

事实证明，如果我们具有该工具，则可以在IntelliJ IDEA中相当好地完成此操作：

选择版本控制|显示更改视图。

在左侧，选择存储库，然后单击要查看的所有修订。

在右侧窗格中，我们将获得受所选修订影响的所有文件的列表。当我们选择" diff"时，我们将在所选变更集中看到内部变更。提交中发生的内部重做未显示(可以预期)

回答

请参阅我们的http://www.semdesigns.com/Products/SmartDifferencer/index.html
用于由语言语法参数化的工具，并根据插入，删除，移动，替换或者在其上始终替换的标识符的语言元素(标识符，表达式，语句，语句，块，方法等)产生增量。此工具会忽略空格重新格式化(例如，不同的换行符或者布局)和语义上无法区分的值(例如，它知道0x0F和15是相同的值)。

这不会因为根本不同的原因而使两组更改分开。
但这将最小化我们必须检查的增量的大小，这肯定会
帮助。

我们说文件长数千行。听起来像COBOL。有一个针对C＃，PHP，Java，C ++ ...和COBOL的智能差异工具，并在网站上提供了其中大多数的示例。

回答

一种方法(使用颠覆术语，但类似的方法也应与其他系统一起使用)：

在第一次更改之前，请在修订版本中签出工作副本。然后将所有相关的提交合并到工作副本中。

现在，我们有了一个工作副本，该工作副本与基本副本的区别仅在于相关更改。我们可以直接对其进行审核，也可以从中创建补丁进行审核。

如果基本修订后的一些不相关的更改与待审核的更改重叠，则可能会发生合并冲突，但是这种情况很少见。

回答

从Subversion的角度来看

根据要求，我将通过与上次检查中的标记进行比较来运行代码检查；即两个标签之间的差异。

回答

如果我们有能力切换源代码控制系统，则可以认真考虑git(或者Mercurial或者其他类似工具)。

每个开发人员都创建自己的本地存储库。

对于他们处理的每个错误，他们都会创建一个分支。

完成更改后，他们可以使用rebase命令将更改捆绑到一致的检查点中，以处理历史记录。

然后，开发人员将重新设置的变更集提交进行审查。

然后，集成者或者审阅者可以按原样接受更改，选择获取他们想要保留的内容，和/或者进行更多的调整以拆分不应组合在一起的提交。

回答

patchutils软件包包含一个combindiff工具，该工具可以"从两个增量补丁创建累积的统一补丁"。

回答

我几乎会按照建议去做。创建一个评论分支。让正在审查其更改的开发人员将樱桃挑入该分支。将头部的根部与根部分开。

我可能还会创建一个小工具来获取所有与给定的bug跟踪id标记匹配的签入，并将它们合并到一个近似的脚本中进行挑选。我一定会给用户一个在运行该脚本之前对其进行编辑的机会，因为我敢打赌有些东西会被误标记。

在分支上进行审查。在分支上进行任何编辑。 Cherry将所做的编辑返回到主干。如果我们不再想要该评论分支，则将其丢弃。