Gerrit多次commit造成多次review请求的解决方法

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.youkuaiyun.com/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

               

这是Gerrit的设计决定的，这绝对不是bug。每次commit都会生成一个change id，而review请求就是绑定在这个change id上的。

两种解决方法：

1.工程师尽可能的少用commit, 每次都用git add 将工作区的东西放到暂存区管理，然后在git push review之前一次调用git commit

2.很多人建议：第一次调用git commit , 之后通过git commit --amend -m' ' 命令来对前面的提交进行修订，确保只产生一个commit和与之对应的change id

然后再git push review

review流程中：

如果一个review请求没有被审批者通过，审批着添加了注释，并要求重新修改代码，工程师也应该总使用第二种方法，这样就不会改变change id.

实践中，我发先git commit --amend 还是产生了新的change id，因为commit id相同，不代表change id就不会新产生。

解决方法是：

git commit --ammend 写注释的时候末尾加上如下的格式字符串：

Change-Id: I835802a16c90ea08d181b51facee7bd153ae9749

这个change id可以通过Gerrit系统站点上找到。参考下文。

再次请求就作为该review的补丁继续请求。

在本地git仓库中，可以通过命令观察到远程Gerrit维护的Git库中的review任务：

 git ls-remote origin8a0472420559380dc4fb0c67d7268d6b46a78888 HEADae654d61b7d06e311ec1a6a9012df71f30f2f993 refs/changes/16/116/18a0472420559380dc4fb0c67d7268d6b46a78888 refs/heads/master32a17f0e3528aa25d90674b4836f1a91235122e2 refs/meta/config

上面的结果显示了Gerrit维护的中心仓库中，有意个change id为

ae654d61b7d06e311ec1a6a9012df71f30f2f993

到Gerrit网站上看一下：

除了多一个I开头，change id相同。

还可以看到patch set

refs/changes/16/116/1

           

给我老师的人工智能教程打call！http://blog.youkuaiyun.com/jiangjunshow