Question

所以情况如下：

我正在审核有超过30项提交的大任务。已经完成了一个审核和修复周期，现在我想查看仅修复。问题是，同时大约200个提交从主服务器合并到功能分支：

for (Entry *entry in array) {
    NSLog(@"lat: %@ - long: %@", entry.latitude, entry.longitude);

}

如何将code review ↓ B---D---F---H---J---L---M---N---O feature ↗ ↗ --A---C---E---G---I---K master到H范围的变化区分为O，同时忽略合并中的内容？

由于许多冲突，重新定位很麻烦。

Answer 1

假设L是合并提交，您可以在O上创建临时分支，检查它然后运行git rebase --onto J L。这样，新分支会跳过L提交，git diff F仅包含提交H, J, M, N, O引入的更改。确保在开始之前没有未提交的更改。现有分支机构不受影响。

命令是：

git checkout -b temp O
git rebase --onto J L
git diff F

当您结束审核时，您可以运行：

git checkout feature
git branch -D temp

再次结帐feature并删除临时分支。

Answer 2

你提到变基会产生很多冲突。这告诉我，M到O中的代码可能依赖于合并，并且在没有合并的情况下进行审核可能是徒劳无功的努力。也就是说，你可以尝试一些事情：

一个选项是签出功能，创建临时分支，并在临时分支上恢复L。这将创建一个新的提交~L，您可以将其与F进行比较。如果rebase尝试产生冲突，这也可能产生冲突;但至少你只有一个决议步骤。

另一种选择是分两步审查。首先将F与J进行比较，然后将L与O进行比较。这意味着要查看两个补丁，但如果这是两个中等大小的补丁而不是一个巨大的补丁，主要包含＆＃34; noise＆＃34;，它仍然可能是一个胜利。