写在前面：
如本文描述有错误，希望读到这篇文章的您能够提出批评指正。 联系方式：172310978@qq.com
参考文章：
好久没有提交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 ， 发现这哥们出错的结果与我很类似：
底下的高赞答案建议这么修改：
1 | I got the same message. And it was because I have managed to get the same Change-Id for two commits. |
大概意思就是删除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压缩成一个。
1 | git rebase -i HEAD~\[number\_of\_commits\] |
如果你想要压缩最后三个commit，你需要运行下列命令（注意：如果一共有4次提交，则只能压缩后3次提交！不能执行 git rebase -i HEAD~4 ）：
1 | git rebase -i HEAD~3 |
为了模拟实际git rebase效果，我们先在git上提交两个修改。git log如下：
1 | commit 7b16b280f22fe4ff57c1879867a624f6f0f14398Author: pan Date: Sun Apr 22 08:55:32 2018 +0800 update3 |
假设合并这3个提交，可以按照下面过程
1 | git rebase -i HEAD~3 |
执行命令后终端会出输出： (注意：这里输出的顺序刚好和执行git log命令输出的顺序是相反的！【也就是说 ，旧Commit在前，新的Commit在后】笔者做了多次实验，得出的结果依然如此，而且通过commit id也可以看出来，原文作者在这里是有问题的，大家不要被误导)
1 | pick 16a9a47 update1 |
注：
第一列是rebase具体执行的操作，其中操作可以选择，其中含义如下：
选择pick操作，git会应用这个补丁，以同样的提交信息（commit message）保存提交
选择reword操作，git会应用这个补丁，但需要重新编辑提交信息
选择edit操作，git会应用这个补丁，但会因为amending而终止
选择squash操作，git会应用这个补丁，但会与之前的提交合并
选择fixup操作，git会应用这个补丁，但会丢掉提交日志
选择exec操作，git会在shell中运行这个命令
对比之前的两个提交提交，我觉得第一个提交可以保留，第二个和第三个合并到第一个就可以了。
将第二个和第三个pick改成squash或者s，然后保存退出。如下：
1 | pick 16a9a47 update1 |
此时git会自动将第二个提交合并到第一个提交，并弹出合并提示信息，如下：
1 | \# This is a combination of 3 commits. |
此时我们已经完成了将两个提交合并为一个的处理，可以通过git log查看
1 | commit 4a51759fae9bbd84904029473fe09f8a77f143ed |
-————————————————- 2020/7/29 更新-——————————————————————
有几点需要特别强调下：
比如当前的提交顺序是：
1 | Update 1 // 最老的提交 |
1. 不能对Update1 执行 squash 或者是 fixup 操作，原因上面已经说过了，squash 操作需要与之前的提交合并，但是很明显在合并的这三个提交中，Update 1没有之前的提交；fixup 与 squash 类似，也需要与之前的提交合并，只是会丢弃 comment message。如果此时你对Update 1执行了上述两种操作，git 会报：
1 | error: cannot 'fixup' without a previous commit |
诸如此类的错误。
- 如果只是想合并这三个提交，个人觉得在选择合并策略时，最优的合并方式应该是：
1 | r Update1 // 应用这次提交，但是需要重新编辑Comment message |
这样只需要在接下来重新编辑下合并后的Comment Message就可以了，不会出现像上面原文作者那样一大堆的 comment message, 事实上既然是合并操作，那单条Commit的 Message肯定有很多是不需要的。
总结
注意本文仅仅介绍了我遇到的多个提交合并的问题，关于git rebase用法，建议参考Git Community Book 中文版-rebase和参考资料中的介绍。
多数情况下git rebase仅限在本地使用，也就是在提交到远程分支之前。
参考链接
1. StackOverFlow: Git push remote rejected {change ### closed}
本文转自 https://www.cnblogs.com/yongdaimi/p/12583189.html，如有侵权，请联系删除。