git merge使用不當引起的代碼丟失血案

背景

幾年前大批量的團隊都在轉用git，git的本地庫和分支特性讓代碼管理的便利性大大增長，也由於本地庫和分支的大批量使用致使了代碼之間的頻繁merge，咱們團隊之前就有遇到過git merge之後丟代碼的狀況，表現就是某些變動開發A提交了，通過中間以序列的commit, merge，push，最終某些改動沒了，去看commit history，也沒有相應的變動記錄。一次次commit對比之後老是會找到某次的merge，可是也無法解釋爲何會丟，最後爲了保險一般會選擇beyond compare全量對比一次確保全部丟失的代碼找回來，那是一個痛苦而又讓人睡不安穩的解決辦法。

今天又遇到了一次這個問題，此次的更加詭異，在我查爲何丟的時候，另一個同事提交代碼之後居然丟失的代碼回來了，我當時腦殼裏面只想到一個詞，那就是： 見鬼。可是冷靜下來想，git這種工具出現真丟代碼的機率確定很小，確定是咱們姿式不對。因而認認真真的研究了咱們今天的提交記錄，終於找到答案，就是git merge後只提交部分代碼致使的，這裏順帶提一下，git pull等於git fetch + git merge，因此git pull時也須要特別關注本文提到的問題。

驗證過程

爲了驗證這個問題，我建了一個全新的git庫來複現上述問題，根據咱們遇到的狀況模擬，整個過程我使用三個用戶模擬交叉提交和合並，分別是user1，user2，user3，爲了方便我沒有選擇註冊三個號，而是在提交信息裏面都帶上了名字，能夠製造兩次代碼衝突，而且兩次都進行部分提交。最終的代碼提交記錄以下：

爲了更清晰的看到這個提交過程，我將三個用戶的提交分開來，並根據提交前後作了下面的圖。

代碼怎麼丟的？

首先，第1步和第2步，user1和user2分別在本地作修改，共同修改了file1，只有user2對file2也作了修改，因此若是這兩人的代碼合併，能夠預計合併的時file1會衝突，file2不會。user2修改完成之後作了一次git push，這時候git遠端庫的head應該是指向user2的最後一次提交的。接着user1作git pull，由於file1被兩個用戶修改了，因此須要合併，接着user1處理完衝突之後只提交了file1，沒有提交file2（用命令行須要手動reset，可是用有些GUI工具是能夠選擇只提交file1的）。此時的庫已經丟失了user2:file2:add line的那次改動，這就是血案的開始，丟代碼。能夠對比一下 merge前 和merge後 。

代碼怎麼"恢復"的？

前面只是驗證了代碼怎麼丟，可是事情沒有結束，我上面提到更詭異的是代碼恢復了，這又是怎麼回事呢？user1在第3步合完代碼之後，本身進行了兩次提交，修改了file3和file1，同時，user3加入並本地修改了file1（預計會和user1衝突），接着user1git push，而後user3 git pull，這時候會報file1衝突，一樣，user3犯了user1相似的錯誤，只提交了衝突文件file1。按第3步丟代碼的經驗，file3的改動確定是沒有了，驗證之後確實如此，可是再看看file2的變動呢，它居然又回來了，因此所謂的恢復不是恢復，所謂的丟失沒有丟失，就問你怕不怕。更可怕的是咱們再去看file2的變動歷史。

中間消失和恢復的過程沒有任何變動記錄，這也是以前咱們常常查到無法往下查到地方。從表現上看，是第一次誤操做忽略了這一行的變動，而第二次誤操做，能夠理解爲是忽略了忽略添加這一行的那一次變動，可是，全部的都沒有記錄。

總結

上面的實驗可能看起來有點繁瑣，總結一下，核心的問題就是不要在git merge的時候只提交部分代碼，特別是好多人剛剛用git的時候，運行完成一次git merge，發現本身修改了1個文件，結果git提示要提交100個，這時候當心謹慎的新同窗就會選擇只提交本身的變更吧，卻不知這是在犯大錯啊。除了這種狀況，以前還遇到有的新同窗會修改git默認生成的merge信息，這也是很是很差的習慣，改了之後在查問題的時候沒辦法很容易的看到哪些是merge。因此請注意：

• git merge之後不要部分提交！！

• git merge之後不要部分提交！！

• git merge之後不要部分提交！！

• git merge的信息不要手動改！！

• git merge的信息不要手動改！！

• git merge的信息不要手動改！！

文中提到的實驗庫的地址是： find-the-missing-code, 有興趣的童鞋能夠本身詳細看一下。

本文轉載自： git merge使用不當引起的代碼丟失血案@blog.23lab.com

 

親，若是您感受本文有用，請點個贊再走吧✌(>‿◠)！！