Gerrit: remote rejected HEAD->refs/for/master (change closed) 的问题

好久没有提交code了，主要最近一直在测试，今天把分支的代码merge一下，提交了一版code, 结果Gerrit来了个这么个问题，搞了大半天终于解决了，为了避免下次再遇到所以记录下。现象是这个样子的：

一. 错误现象

如图：Gerrit 扔了一个

! [remote rejected] HEAD -> refs/for/master (change http://btsw5.sdlc.rd.realtek.com/gerrit/2323 closed)
error: failed to push some refs to 'ssh://nisha_chen@btsw5.sdlc.rd.realtek.com:29418/8761BUR/app'

的错误，我第一眼看到这个错误，直觉就是是不是哪次commit没有了？因为Gerrit上提示了：change http://btsw5.sdlc.rd.realtek.com/gerrit/2323 closed ， 然后我就到Gerrit 的web 页面上找2323的这次commit, 果不其然，这次commit 已经被别人merge了：

 

 

而且我注意到，这次commit已经不是最新的了，因为别的同事已经在这次commit之后，提交了新的代码：

 那怎么办呢，虽然我Gerrit不敢说用的有多熟练，但是平时commit 成功的情况都是：本地的commit必须基于Gerrit的最新commit这样才能正常push 过去的。但是我的现在的commit却不是这个样子的：通过执行  git log --oneline 命令发现

我本地的commit 日志是这个样子的：

而Gerrit 服务器上最新的提交日志是这个样子的：

 从图上很明显可以看出来，我的commit记录和Gerrit服务器上的commit记录已经完全不对应了，我本地merge代码后最新的commit记录是 65f6931,(因为之前已经拉过Gerrit上的代码) ，而Gerrit上的最新记录 是de5164e，且Gerrit上 efce048, ef08223, 34fbd21 这几次提交记录都是位于 de5164e这条提交记录之下的，我本地则刚好相反， efce048, ef08223, 34fbd21 这几次提交记录都是位于de5164e这条提交记录之上的。这就尴尬了，提交记录都不对应，合不进去是肯定的。那怎么解决呢，总不能把工作目录拷贝一份，然后从Gerrit上拉最新代码，然后再把不同的文件覆盖掉，再提交吧，我改了好多东西呢，这样太麻烦了。万般无奈，只能求助于Google：

二. 解决办法

在Google上搜索“[remote rejected] head -> refs/for/master (change closed)”，发现匹配的结果确实有不少，看来有不少人像我一样遇到过这个问题呀

打开第一条搜索结果：https://stackoverflow.com/questions/11972384/git-push-remote-rejected-change-closed ， 发现这哥们出错的结果与我很类似：

 底下的高赞答案建议这么修改：

I got the same message. And it was because I have managed to get the same Change-Id for two commits. 
Maybe due to some cherry-picking or similar between my local branches. Solved by removing the Change-Id from the commit message, a new Id then was added by the commit hook.

大概意思就是删除commit message中的 Change id, 我想那行呀，于是执行git commit --amend, 找到Change-Id, 把 Change-id 删了再次提交，结果很遗憾，错误还是一样，不行。

打开第二条搜索结果：https://blog.csdn.net/u014418064/article/details/79039332 ， 看着他描述的错误信息跟我是一样的，但是不知道他说直接abandon掉，不知道要abandon什么，看不懂，不行。

打开第三条搜索结果：https://www.cnblogs.com/yanchengwang/p/6947221.html ， 这哥们直接采用 git push -f  命令，姑且先不说行不行，git push -f 命令我是很不喜欢用的，具体什么原因大家都清楚，强行push commit 一般在公司里是不允许的，可能会引发很严重的问题。

翻来翻去没什么特别好的答案，大多数都是像第一条搜索结果一样，建议直接删除 Change id, 再次push, 可我试了，不行呀。百无聊赖之下，重新打开第一条搜索记录，找找看有没有什么其它的解决办法，我一般看StackOverFlow, 如果高赞答案解决不了问题的时候，喜欢往下再看几条，有时候有些低赞答案才是解决问题的关键，毕竟每个人遇到的问题都不一样，解决途径肯定也不一样。看着看着，有一条结果引起了我的兴趣：

 他给的解决方案大概是说，合并最近的几次提交为一个，合并完了之后再删除合并完的 Commit Message的 Change id, 我想了想，他说的也有道理，我最近的几次提交中有几个已经被Gerrit merge了，但是在我本地看，这些已经被merge的commit 却在Gerrit最新的提交记录之上，要是能把它们合并成一条记录，这样如果将来真的能够push 成功，最起码能够保证 Gerrit 的commit 记录上不会出现一些相同的Commit Message, 那就试试吧，反正死马当活马医呗，实在不行用git reset --hard 恢复就行了。

使用 git log --oneline 命令查看，目前在我本地位于Gerrit最新的Commit之上的记录一共有4条：

合并这四条记录 git rebase -i HEAD~4  :

执行该命令之后，Git出现如下界面，让你选择针对每次提交的操作方式：

我选择的合并策略是保留第一次提交的记录，并且丢掉后面几次提交的Commit 记录（注意，仅仅是丢掉commit的日志，这条记录对应的修改仍然会被应用，所以不必担心这几次提交的修改会丢失）,也就是 102ab44 记录我仍然保持为Pick , 35e44af, 4e45785, 65f6931 这几条记录我修改为 f，修改完毕之后使用wq退出保存：

 

 Git 提示合并已经成功，这个时候git log 再看一下本地的log记录：

 

！！！ 那几条已经被Merge 的记录没有了！而且我本地的最新记录位于Gerrit的最新提交记录之上！这才是正常的提交现象嘛，平时都是这样才能push 成功的，满怀心喜的又提交了一次，结果：

 

Why? 看起来不是已经正常了么？怎么Gerrit还是拒绝我提交呀，满怀失落的我再次运行git log 看了一下：

 无意中发现这条Change-Id 怎么这么眼熟？好像在哪里见过似的，于是打开Gerrit 的web 界面， 找到那个已经被别人Merge的Change-ID:

 

居然一模一样！那肯定是不行的，Change-Id 必须是唯一的，这条Commit既然已经被Merge了，再提交一个相同Change-Id的Commit肯定是不行的呀。于是我突然明白了最开始看的那条高赞答案删除Change-Id的意义，它删除Change-Id的目的原来是为了生成一个新的Change-Id,如果新的Change-Id和已Merge的那条记录的Change-id不一样，那么有可能会成功的。于是我用git commit --amend 再次打开最后一次提交的记录

 

 对之前的Commit信息进行再一次修改之后，删除这里的Change-Id:

 

 wq, 保存退出，再次push :

 看到Git提示终于成功了，打开Gerrit 的web管理界面：

 

界面显示我本次的提交处于：Need Verfied Label 状态，这样才对嘛，我平时看到的提交成功之后的状态就是这个样子。

问题解决完了，心里还是很佩服Git/Gerrit的设计者, 其实工作中遇到的Git问题Git基本都有解，只是一些Git的命令或者是操作方式我们自己不知道罢了，还是那句话，有事不明多Google， 通过这次踩坑之旅我又一次见识了Git的强大。

三. 扩展阅读（Git 合并多个Commit 提交）

这篇文章讲解了如何使用 git rebase 指令来合并多个Commit, 个人觉得还不错，特此分享过来，URL： https://www.jianshu.com/p/29bb983ec48a, 不过他的文章里有些小问题，我会在后面指出。

当你提交代码进行代码审查时或者创建一次pull request (这在开源项目中经常发生)，你的代码在被接受之前会被要求做一些变更。于是你进行了变更，并且直到下一次审查之前你没有再次被要求进行变更过。在你知道又要进行变更之前，你已经有了一些额外的commit。理想情况下，你可以用rebase命令把多个commit压缩成一个。

git rebase -i HEAD~[number_of_commits]

如果你想要压缩最后三个commit，你需要运行下列命令（注意：如果一共有4次提交，则只能压缩后3次提交！不能执行  git rebase -i HEAD~4 ）：

git rebase -i HEAD~3

为了模拟实际git rebase效果，我们先在git上提交两个修改。git log如下：

commit 7b16b280f22fe4ff57c1879867a624f6f0f14398Author: pan Date:   Sun Apr 22 08:55:32 2018 +0800    update3
commit a7186d862b95efc5cc1d7c98277af4c72bac335dAuthor: pan Date:   Sun Apr 22 08:55:16 2018 +0800    update2 
commit 16a9a4749f8ee25ab617c46925f57c2fa8a4937eAuthor: pan Date:   Sun Apr 22 08:54:55 2018 +0800    update1

假设合并这3个提交，可以按照下面过程

git rebase -i HEAD~3

执行命令后终端会出输出： (注意：这里输出的顺序刚好和执行git log命令输出的顺序是相反的！【也就是说 ，旧Commit在前，新的Commit在后】笔者做了多次实验，得出的结果依然如此，而且通过commit id也可以看出来，原文作者在这里是有问题的，大家不要被误导)

pick 16a9a47 update1 
pick a7186d8 update2
pick 7b16b28 update3
 # Rebase a9269a3..7b16b28 onto a9269a3 (3 commands)
 #
 # Commands:
 # p, pick = use commit
 # r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out~  

注：

第一列是rebase具体执行的操作，其中操作可以选择，其中含义如下：

选择pick操作，git会应用这个补丁，以同样的提交信息（commit message）保存提交

选择reword操作，git会应用这个补丁，但需要重新编辑提交信息

选择edit操作，git会应用这个补丁，但会因为amending而终止

选择squash操作，git会应用这个补丁，但会与之前的提交合并

选择fixup操作，git会应用这个补丁，但会丢掉提交日志

选择exec操作，git会在shell中运行这个命令

对比之前的两个提交提交，我觉得第一个提交可以保留，第二个和第三个合并到第一个就可以了。

将第二个和第三个pick改成squash或者s，然后保存退出。如下：

pick 16a9a47 update1 
s a7186d8 update2
s 7b16b28 update3

此时git会自动将第二个提交合并到第一个提交，并弹出合并提示信息，如下：

# This is a combination of 3 commits.
# This is the 1st commit message:
update1 
 # This is the commit message #2:
 update2 
 # This is the commit message #3:
 update3
 # Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Sun Apr 22 08:54:55 2018 +0800
#
# interactive rebase in progress; onto a9269a3
# Last commands done (3 commands done):
#    s a7186d8 update
#    s 7b16b28 update6666
#  No commands remaining.

如果需要修改下提交信息，如果不需要直接保存退出即可。

# This is a combination of 3 commits. 

合并提交测试

# Please enter the commit message for your changes. Lines starting 

# with '#' will be ignored, and an empty message aborts the commit. 

# 

# Date:      Sun Apr 22 08:54:55 2018 +0800 

# 

# interactive rebase in progress; onto a9269a3 

# Last commands done (3 commands done): 

#    s a7186d8 update 

#    s 7b16b28 update6666 

#  No commands remaining.

此时我们已经完成了将两个提交合并为一个的处理，可以通过git log查看

commit 4a51759fae9bbd84904029473fe09f8a77f143ed
Author: pan 
Date:   Sun Apr 22 08:54:55 2018 +0800    合并提交测试

---------------------------------- 2020/7/29 更新---------------------------------------------

有几点需要特别强调下：

比如当前的提交顺序是：

Update 1    // 最老的提交
Update 2
Update 3    // 最新的提交

1. 不能对Update1 执行 squash 或者是 fixup  操作，原因上面已经说过了，squash 操作需要与之前的提交合并，但是很明显在合并的这三个提交中，Update 1没有之前的提交；fixup 与 squash 类似，也需要与之前的提交合并，只是会丢弃 comment message。如果此时你对Update 1执行了上述两种操作，git 会报：

error: cannot 'fixup' without a previous commit
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.

诸如此类的错误。

2. 如果只是想合并这三个提交，个人觉得在选择合并策略时，最优的合并方式应该是：

r Update1     // 应用这次提交，但是需要重新编辑Comment message
f Update2     // 丢弃Update2的Comment Message, 与Update1合并
f Update3     // 丢弃Update3的Comment Message，与Update2合并 

这样只需要在接下来重新编辑下合并后的Comment Message就可以了，不会出现像上面原文作者那样一大堆的 comment message, 事实上既然是合并操作，那单条Commit的 Message肯定有很多是不需要的。

总结

注意本文仅仅介绍了我遇到的多个提交合并的问题，关于git rebase用法，建议参考Git Community Book 中文版-rebase和参考资料中的介绍。

多数情况下git rebase仅限在本地使用，也就是在提交到远程分支之前。

参考链接

1. StackOverFlow: Git push remote rejected {change ### closed}

2. 简书：Git 合并多个Commit提交