好久沒有提交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提交