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回滾等操作需謹慎對待
「用來記錄生命的演進，故事的迭代。
[limiyoyo ] 淺析git server「丟失」commit問題已經有239次圍觀
