一、問(wèn)題回顧

問(wèn)題是git commit --amend 引起的。 一條commit已經(jīng)push到遠(yuǎn)端develop了，但是后來(lái)又在這條commit上進(jìn)行了amend操作，導(dǎo)致這條commit的哈希碼發(fā)生了變化。并且后續(xù)又在這條commit之后進(jìn)行了N條commit操作。

<Begin>

大概的情況畫了個(gè)簡(jiǎn)圖，如圖所示。下面的綠色就是最后相同的地方，紅色的那條做的是相同的功能message是一樣的，但是提完develop之后又改動(dòng)了很多然后使用amend擠壓了。

這個(gè)時(shí)候比較頭疼了，因?yàn)槟菞lamend的commit里面是發(fā)生了太多改動(dòng)，我采用的是可以避免沖突的方法，但是會(huì)改develop的commit樹(shù)

git checkout developgit reset 2c4532 //上面97，98，99的改動(dòng)會(huì)被放出來(lái)git stash //先把這些改動(dòng)存起來(lái)git reset --hard 5d67bc //等于是把96完全剔除了，代碼回到了95的狀態(tài)git cherry-pick 8a6f7f //把那一條修改后的功能commit（96的feature）粘貼過(guò)來(lái)，這一步100%不會(huì)有沖突git stash pop //把之前存起來(lái)的那些改動(dòng)再放出來(lái)，這一步不能保證100%無(wú)沖突，但實(shí)際由于兩個(gè)功能模塊離得比較開(kāi)，所以也沒(méi)有發(fā)生沖突。git add . git commit -m " " //把develop上面的97，98，99三條commit 擠壓成了一條后commitgit cherry-pick 86f6cc d34c7 2817f5 //這一步把feature分支的97，98，99三條commit粘貼過(guò)來(lái)，因?yàn)檫@三條基本是基于8a6f7f開(kāi)發(fā)的，所以也沒(méi)有發(fā)生沖突。 董鉑然博客園

<End>

這樣改完之后develop的commit樹(shù)如上圖所示（第97條就是把之前的97，98，99擠壓成的1條），可以編譯通過(guò)功能都能實(shí)現(xiàn)。 但是缺點(diǎn)是這時(shí)候需要強(qiáng)推develop了。

?

組里另一個(gè)人提出的解決方案是

<Begin>（圖再貼一遍 省的往上翻）

git checkout feature //操作都在feature分支進(jìn)行，不動(dòng)develop的代碼git reset 5d67bc //把feature分支上“不科學(xué)”的commit 96，97，98，99 全部放出來(lái)git stash //全部臨時(shí)存起來(lái)git rebase develop //快進(jìn)一下，合入了所有develop的新代碼 100%無(wú)沖突git stash pop //把之前揉在一起的4條commit的代碼一起放出來(lái)，這時(shí)候會(huì)有大量沖突。git add . git commit -m "fix" //解決沖突后commit一下 //然后再把最后的一條commit merge入develop，最后的結(jié)果時(shí)develop如下

<End>

可以看出這種做法，不需要強(qiáng)制push develop的代碼。理論上更加科學(xué)，但是中間需要解決大量的沖突。

事后反省一下，覺(jué)得兩種方法其實(shí)各有優(yōu)劣，如果組內(nèi)成員不多，可以在大家的監(jiān)督下 完成強(qiáng)推develop的操作。 因?yàn)榻鉀Q了大量沖突可能會(huì)比 非常清晰了解差異后-f強(qiáng)推develop更容易出現(xiàn)錯(cuò)誤。 當(dāng)然如果是大型項(xiàng)目，幾十人團(tuán)隊(duì)，并且遠(yuǎn)端都綁上了編譯檢查，和merge規(guī)則的項(xiàng)目也只能使用第二種方法了。

?

二、其他經(jīng)驗(yàn)

對(duì)于一個(gè)碼農(nóng)而言，比寫出bug更恐怖的是把代碼弄丟了或弄亂了。 對(duì)于這種問(wèn)題也是有一種統(tǒng)一的解決方案

①.git reset --hard ?哈希碼 ， 這條非常普遍，如果出現(xiàn)問(wèn)題有點(diǎn)亂直接回到一個(gè)安全的commit

②.git reflog ? ?對(duì)于有rebase或merge這種操作，第一條指令就用不了了，因?yàn)楸晃廴镜牟⒉粌H僅是最后一條commit。 這時(shí)要用這個(gè)萬(wàn)能恢復(fù)指令，回到一個(gè)操作的哈希碼。

③.但是前兩種方法都是對(duì)于一些已經(jīng)加入過(guò)git的代碼進(jìn)行恢復(fù)。 如果一些代碼還沒(méi)有commit 這時(shí)候弄丟了 那些指令就都幫不了你了。 這時(shí)候只能看IDE有沒(méi)有l(wèi)ocal history了。(local history相當(dāng)于IDE幫你實(shí)現(xiàn)了一個(gè)類似于git的功能)之前就有過(guò)一次第3種情況的經(jīng)歷，當(dāng)時(shí)是把沒(méi)commit的代碼給reset了 使用localhistory得以恢復(fù)。好在現(xiàn)在iOS的xcode 和 Android的Android Studio都是有l(wèi)ocal history的，

• Xcode 的local history在 導(dǎo)航欄 → View → Version Editor → show Version Editor?
• Android Studio 的local history在 左邊文件目錄 → 選中根目錄 → show local history

?

如果上文說(shuō)的問(wèn)題有更好的解決方案，也歡迎一起討論。

總結(jié)

以上是生活随笔為你收集整理的记一次git amend事故处理方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。