1 背景

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

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

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

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

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，并無有效線索。并且同時段的其他倉庫可以看到commit信息

2.2 gitlab network graph尋找線索

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

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

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

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

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

3 結(jié)論

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

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

A. 將dev等需重點分支禁止force push

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

“用來記錄生命的演進(jìn)，故事的迭代。期望做一個給大家?guī)韼椭退伎嫉钠脚_” ——深邃老夏

到此這篇關(guān)于淺析git server“丟失”commit問題的文章就介紹到這了,更多相關(guān)git server“丟失”commit內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論