好久没有提交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，你需要运行下列命令。
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
执行命令后终端会出输出：
pick 16a9a47 update3 pick a7186d8 update2 pick 7b16b28 update1 # 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 update3
s a7186d8 update2
s 7b16b28 update1
此时git会自动将第二个提交合并到第一个提交，并弹出合并提示信息，如下：
# This is a combination of 3 commits. # This is the 1st commit message: update3 # This is the commit message #2: update2 # This is the commit message #3: update1 # 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 合并提交测试
总结
注意本文仅仅介绍了我遇到的多个提交合并的问题，关于git rebase用法，建议参考Git Community Book 中文版-rebase和参考资料中的介绍。
多数情况下git rebase仅限在本地使用，也就是在提交到远程分支之前。
参考链接
1. StackOverFlow: Git push remote rejected {change ### closed}
2. 简书：Git 合并多个Commit提交