Question

我们最近介绍了gerrit在我们的团队中使用代码审查工具。现在有一个问题，我想与你讨论我的解决方案。

问题：开发人员正在修复一些小错误，并希望使用代码审查来进行这些更改。由于问题ID，他正在为每个错误修复创建一个更改集。所有的变化都转到了“发展”的分支。与此同时，有一位评论员，他对一些代码更改有些怀疑。他（验证者）要求开发人员更改特定更改集（SHA 1234）上的内容，而不是最后一个。

此时开发人员的树是：

A＆lt; -B＆lt; -SHA1234＆lt; -D＆lt; -E

A和B已经审核并提交的提交; SHA1234将被更改; D是一个完全不同的补丁集，已经被推向了格里特; E将是一个完全不同的补丁集（它是一个现在不存在于gerrit中的提交）。

现在该怎么办？

我建议的解决方案是这样的：

...删除列表中的过时提交并保存+关闭编辑器。

将tmp合并回开发并删除tmp分支

git checkout develop
git merge tmp
git branch -d tmp

Answer 1

他要求开发人员提供特定更改集（SHA 1234）的补丁，这不是最后一个。现在该怎么办？

使用gerrit应该很容易，特别是因为他为每个bugfix创建了一个补丁集。

首先，因为我一直使用gerrit＆＃34;旧屏幕＆＃34;并且还没有找到如何使用＆＃34;新屏幕＆＃34;，您可能想要将您的设置为＆＃34;旧屏幕＆＃34;同样。

在设置中 - ＆gt;偏好 - ＆gt;改变观点

然后，在您想要检索的特定补丁集的页面上，您应该看到此部分

在这里，他有几个选项，你可以看到。结帐/拉/樱桃挑选/补丁。他可以选择他需要的选项，然后复制出现的链接并将其粘贴到git终端中。

我经常使用这个例子来挑选一个新的提交到我的本地开发分支来验证Android设备上的一些新代码，因为它并不总是很容易看到它是如何以及它是否有效在代码。

编辑：

原始开发者还有一些进一步的提交。所以树对sha1234有依赖性。但他必须更改sha1234才能应用代码审查结果。必须重新设置将sha1234作为父项的提交。当然，这也影响了他已经拥有的所有以下提交并导致一些冲突......

最初的问题是：解决这种情况的建议方式（上述步骤）是否错误？

这不一定是错的，但我觉得有一种更简单的方法。

在提交1234之前返回的交互式rebase是

$ git rebase -i HEAD~5  # replace 5 with how many commits back 1234 is

将提交1234设置为＆＃39;编辑＆＃39;其余的选择＆＃39; （选择应该是默认值）。退出nano / vim并确认。
您将被带回1234.您可以在此处进行编辑并修改提交。（注意：修改提交会更改其哈希值）
$ git rebase --continue git现在将尝试在修改后的1234之上重新应用其他提交。
- 如果没有冲突：很好，你现在已经完成了变基。
- 如果他们这样做：以您喜欢的方式解决冲突，并使用git add或git rm标记冲突。然后再次git rebase - 继续。重复此步骤，直到解决所有冲突。你现在应该回到你开始的地方，但历史已经改变了。
现在，由于所有这些提交都已更新（1234已修改，其他提交有更新的父/依赖关系），您需要将它们全部重新推送到gerrit。这应该像执行$ git push origin HEAD:refs/for/develop一样简单，gerrit会自动检测哪些补丁集已经收到更新。

我在这里更详细地解释了这个过程：Modifying old commit in git