如何解決git server“丟失”commit問題

小編這次要給大家分享的是如何解決git server“丟失”commit問題，文章內容豐富，感興趣的小伙伴可以來了解一下，希望大家閱讀完這篇文章之后能夠有所收獲。

1 背景

gitlab某倉庫有同事發現部分代碼文件內容丟失，具體表現

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

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

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

2 追查過程

2.1 gitlab server側尋找線索

表面上像是gitlab server出現了某些問題導致“丟失”，所以查看/var/log/gitlab/gitlab-rails/下的production.log日志（production.log是當天的，production.log.31.gz是更早日期壓縮后的，需要解壓查看）。

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

2.2 gitlab network graph尋找線索

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

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

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

此提交為d5049b0，可以看到該文件已經沒有bfff1f51提交了

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

3 結論

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

4 建議的改進措施：

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

B. 開發人員對于git回滾等操作需謹慎對待

看完這篇關于如何解決git server“丟失”commit問題的文章，如果覺得文章內容寫得不錯的話，可以把它分享出去給更多人看到。