git server“丟失”commit問題探究

1 背景

gitlab某倉庫有同事發(fā)現(xiàn)部分代碼文件內(nèi)容丟失，具體表現(xiàn)

A. dev分支commit信息是連續(xù)的奠伪，看不出明顯的大時(shí)間范圍批量丟失

file

B. 以SuncardCashier/control/CSymbolEdit.h為例跌帐，在1c88f613下只能看到2個(gè)歷史相關(guān)提交

file

但是1天前提交的bfff1f51，也有此文件的修改提交绊率，意味著bfff1f51這個(gè)提交“丟失”了

2 追查過程

2.1 gitlab server側(cè)尋找線索

表面上像是gitlab server出現(xiàn)了某些問題導(dǎo)致“丟失”谨敛，所以查看/var/log/gitlab/gitlab-rails/下的production.log日志（production.log是當(dāng)天的，production.log.31.gz是更早日期壓縮后的滤否，需要解壓查看）佣盒。

但是通過查看日志只有一些查看上述commit的api access log，并無有效線索顽聂。并且同時(shí)段的其他倉庫可以看到commit信息

2.2 gitlab network graph尋找線索

此時(shí)懷疑是有人在本地誤使用rebase等命令再force push導(dǎo)致server的commit丟失肥惭，通過gitlab的network graph是一個(gè)高效的梳理手段

首先在network grapsh搜索bfff1f51（灰色箭頭指向），這也說明gitlab server其實(shí)有此commit數(shù)據(jù)

file

這里不同顏色線相當(dāng)于是dev分支不同的提交人紊搪，最右側(cè)紅線為主分支蜜葱，其中線之間的箭頭是merge。查看圖中bfff1f51之后各線最鄰近的merge耀石，基本都還可以看到bfff1f51這個(gè)提交牵囤，說明正常。除了紅色箭頭標(biāo)識(shí)的左側(cè)綠線滞伟！

file

此提交為d5049b0揭鳞，可以看到該文件已經(jīng)沒有bfff1f51提交了

file

繼續(xù)到綠線分支更后的操作追查，之后它merge到了粉線（左起第二）梆奈，粉線再merge到了蘭線（左起第三）野崇，粉線再merge到了紅線（左起第四）。而“丟失”情況如下圖示亩钟，即被綠線merge前都正常乓梨，merge后都丟失了

file

3 結(jié)論

至此，可以基本確定是d5049b0進(jìn)行了類似rebase回滾到之前提交的行為（其commit message也填寫的是“沖突”）清酥，另外可以看到該倉庫設(shè)置的protected branch只有master扶镀，無dev，所以是具備force push條件的

file

4 建議的改進(jìn)措施：

A. 將dev等需重點(diǎn)分支禁止force push

B. 開發(fā)人員對(duì)于git回滾等操作需謹(jǐn)慎對(duì)待

“架構(gòu)人生焰轻，迭代生命” ——深邃老夏臭觉，搜索summer_deep微信公眾號(hào)可獲取更多幫助

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者