指南：reflog與fsck找回誤刪提交的實(shí)操)
很多開發(fā)團(tuán)隊(duì)其實(shí)都經(jīng)歷過類似場(chǎng)景一個(gè)重要功能已經(jīng)開發(fā)完成但因?yàn)榉种Ч芾聿灰?guī)范、提交沒有及時(shí)推送遠(yuǎn)端等到要發(fā)布時(shí)才發(fā)現(xiàn)本地倉(cāng)庫(kù)已經(jīng)被覆蓋或誤清理最后只能加班翻找、甚至返工。標(biāo)題里“上一把丟了的大紅這把總算是帶出去了”放在業(yè)務(wù)里看就是一個(gè)很典型的故事“大紅”是內(nèi)部負(fù)責(zé)的某個(gè)核心模塊上一輪開發(fā)時(shí)把它的變更弄丟了這一輪通過完善的分支策略和發(fā)布流程總算把功能安全地帶到了測(cè)試環(huán)境、生產(chǎn)環(huán)境。這篇文章不以閑聊為主而是依托這個(gè)場(chǎng)景完整梳理一套“Git 分支丟失后的找回操作 可實(shí)現(xiàn)安全交付的分支發(fā)布流程”。內(nèi)容會(huì)包括誤刪分支如何通過 reflog 和 fsck 找回、找回后怎么驗(yàn)證和恢復(fù)、如何避免再次出現(xiàn)同樣的問題以及從本地開發(fā)到制品發(fā)布的一整套工程化操作。無論你是剛接觸 Git 的新手還是需要規(guī)范交付流程的后端開發(fā)、測(cè)試同學(xué)都可以從這篇文章里找到直接能用的命令和方案。1. 先理解“丟了一把”到底丟的是什么1.1 “大紅”在這里指的是什么在真實(shí)項(xiàng)目中“大紅”大概率會(huì)是一個(gè)業(yè)務(wù)模塊的代號(hào)比如商城項(xiàng)目的訂單模塊、支付模塊、用戶積分模塊。為了敘述方便本文統(tǒng)一把目標(biāo)模塊稱為 BigRed在 Git 倉(cāng)庫(kù)中表現(xiàn)為一個(gè)功能分支例如feature/bigred-optimize。很多項(xiàng)目里的命名習(xí)慣并不統(tǒng)一有人用日期、有人用需求單號(hào)、有人用本地拼音縮寫。命名本身不是最要緊的最要緊的是這個(gè)分支上承載的代碼提交必須有且只有一個(gè)權(quán)威來源。上一把丟失的往往不是“代碼本身的字符”而是這些提交的引用關(guān)系。換句話說代碼對(duì)象可能還在 Git 對(duì)象庫(kù)里但我們已經(jīng)找不到指向它的分支指針了于是它成了“懸空提交”。所以先建立一個(gè)認(rèn)知在 Git 體系里“一個(gè)分支”本質(zhì)上只是一個(gè)可移動(dòng)的指針指針指向某一次 commit而 commit 又串聯(lián)出完整的提交歷史。分支被刪除時(shí)Git 只是刪除了這個(gè)指針并不會(huì)立刻物理刪除所有對(duì)象。明確這個(gè)概念對(duì)后續(xù)找回操作會(huì)非常有幫助。1.2 所謂“丟失”大多數(shù)情況不是代碼消失先說結(jié)論在大部分沒有執(zhí)行g(shù)it gc或?qū)ο笪幢磺謇淼那闆r下誤刪分支、git reset --hard之后的提交都依然殘留在.git目錄中。我們可以通過 Git 自帶的 reflog 機(jī)制把過去 HEAD 指針的移動(dòng)軌跡找出來再重新為對(duì)應(yīng)提交創(chuàng)建一個(gè)新分支。舉一個(gè)高頻發(fā)生的丟失場(chǎng)景開發(fā)者在feature/bigred-optimize分支上提交了好幾個(gè) commit但為了“保持本地干凈”某天執(zhí)行了git checkout master接著想重置當(dāng)前分支到遠(yuǎn)端狀態(tài)卻誤選了git reset --hard origin/master。這時(shí)本地分支的引用被強(qiáng)制移到了遠(yuǎn)端 master 的位置之前那幾個(gè) commit 就暫時(shí)“看不到”了。好在只要沒有觸發(fā)垃圾回收git reflog里還留著一長(zhǎng)串記錄。另一個(gè)高頻場(chǎng)景是執(zhí)行g(shù)it branch -D feature/bigred-optimize刪除了本地分支但該分支從未推送到遠(yuǎn)端遠(yuǎn)程origin/bigred-optimize不存在。這種情況相對(duì)危險(xiǎn)但依然有較高概率通過 HEAD 的 reflog 恢復(fù)。還有一種情況是完全未提交的代碼被覆蓋例如工作區(qū)修改還沒git commit直接執(zhí)行了git checkout .或git clean -fd。這種情況下未提交內(nèi)容基本不會(huì)出現(xiàn)在 reflog 中恢復(fù)成功率很低。所以文章后面會(huì)特別強(qiáng)調(diào)“小步提交 及時(shí)推送”的價(jià)值。1.3 這類問題的定位思路當(dāng)發(fā)現(xiàn)自己“把提交弄丟了”不要急著亂執(zhí)行命令先按照下面的順序做一次快速評(píng)估是否知道最后一次提交的 commit hash本地git reflog是否還能看到這條記錄遠(yuǎn)端是否曾經(jīng)存在對(duì)應(yīng)分支是否有人已經(jīng)拉取過這個(gè)分支并可能緩存了提交是否執(zhí)行過git gc或者長(zhǎng)時(shí)間沒有操作一旦明確當(dāng)前狀態(tài)就能選擇對(duì)應(yīng)的找回方案。后面第三節(jié)會(huì)給出具體命令但在此之前最好準(zhǔn)備一個(gè)干凈的環(huán)境來演練。下面先統(tǒng)一環(huán)境說明。2. 環(huán)境準(zhǔn)備與版本說明2.1 本地 Git 環(huán)境本文所有命令都基于 Git 命令行完成操作系統(tǒng)可以是 Windows、Linux 或 macOS。只要你的環(huán)境里已經(jīng)安裝 Git并能在終端執(zhí)行g(shù)it --version就可以繼續(xù)操作。git --version如果你還沒有配置用戶信息先做一次基礎(chǔ)設(shè)置git config --global user.name your-name git config --global user.email your-emailexample.com這里不強(qiáng)制指定 Git 的具體大版本因?yàn)?reflog、branch、fsck 等命令在 Git 2.x 版本中表現(xiàn)基本一致。如果你的項(xiàng)目使用的是老版本 Git建議先升級(jí)避免某些命令輸出格式不同。2.2 示例倉(cāng)庫(kù)與模塊命名為了演示我們可以在本地創(chuàng)建一個(gè)模擬倉(cāng)庫(kù)。倉(cāng)庫(kù)名定為demo-bigred-project里面模擬 BigRed 模塊的開發(fā)提交。后續(xù)的操作會(huì)展示如何創(chuàng)建分支、提交代碼然后模擬誤刪再執(zhí)行找回。mkdir demo-bigred-project cd demo-bigred-project git init這里先建立一條主分支提交作為項(xiàng)目基線git checkout -b main echo # Demo BigRed Project README.md git add README.md git commit -m docs: init project接下來創(chuàng)建 BigRed 模塊的功能分支并模擬開發(fā)git checkout -b feature/bigred-optimize mkdir -p src/main/java/com/example/bigred echo public class BigRedService {} src/main/java/com/example/bigred/BigRedService.java git add . git commit -m feat: init bigred service上述命令并不復(fù)雜但它模擬了真實(shí)開發(fā)里“工作從分支開始”的動(dòng)作。之所以強(qiáng)調(diào)分支而不是直接在 main 上開發(fā)是因?yàn)?main 分支通常承擔(dān)穩(wěn)定發(fā)布的責(zé)任不應(yīng)該塞入未驗(yàn)證的功能代碼。2.3 實(shí)驗(yàn)前準(zhǔn)備一份“可回退”的倉(cāng)庫(kù)找回類操作有一定風(fēng)險(xiǎn)尤其是當(dāng)你對(duì)倉(cāng)庫(kù)不熟悉時(shí)不要在重要的生產(chǎn)倉(cāng)庫(kù)上直接嘗試。更好的方式是把相關(guān)歷史先備份到一個(gè)獨(dú)立目錄cp -r demo-bigred-project /tmp/demo-bigred-project-backup或者使用 Git 自帶的 clone 方式備份git clone --mirror demo-bigred-project /tmp/demo-bigred-project.git.bak--mirror會(huì)克隆一個(gè)包含所有 refs 的裸倉(cāng)庫(kù)能覆蓋本地分支、遠(yuǎn)端分支、Tag 等引用信息。遇到重要倉(cāng)庫(kù)恢復(fù)場(chǎng)景先做鏡像備份是比較穩(wěn)妥的習(xí)慣。3. 找回誤刪分支與提交的核心操作3.1 用 git reflog 找回最近移動(dòng)過的提交git reflog是 Git 提供的一份“操作日志”它記錄 HEAD 指針在過去一段時(shí)間內(nèi)的移動(dòng)歷史。只要沒有手動(dòng)清理.git/logs尋找最近丟失的分支提交通常非常有效。在示例倉(cāng)庫(kù)中執(zhí)行g(shù)it reflog --dateiso輸出可能包含類似下面的記錄a1b2c3d HEAD{0}: checkout: moving from feature/bigred-optimize to main b2c3d4e HEAD{1}: commit: feat: init bigred service a1b2c3d HEAD{2}: checkout: moving from main to feature/bigred-optimize從實(shí)際經(jīng)驗(yàn)看reflog 的保留時(shí)間并不是無限長(zhǎng)。它和倉(cāng)庫(kù)的 gc 策略、提交數(shù)量、倉(cāng)庫(kù)使用頻率都有關(guān)默認(rèn)配置下通常能保留一段時(shí)間但如果你希望更穩(wěn)妥可以在全局或倉(cāng)庫(kù)級(jí)配置中適當(dāng)延長(zhǎng)保留周期。例如git config gc.reflogExpire 180.days git config gc.reflogExpireUnreachable 30.days上面第一條配置影響“仍然可達(dá)的 reflog 條目”的過期時(shí)間第二條影響“不可達(dá)條目”的過期時(shí)間。不同團(tuán)隊(duì)可以按提交頻率調(diào)整但要記得reflog 不是版本管理的備份工具它只是幫助你最后看一眼操作軌跡。3.2 用 git branch 重建分支當(dāng)通過 reflog 找到目標(biāo) commit hash 后重建分支只需要一條命令git branch feature/bigred-optimize commit-hash假設(shè)在 reflog 中看到的 BigRed 模塊提交 hash 是b2c3d4e那么執(zhí)行g(shù)it branch feature/bigred-optimize b2c3d4e如果想直接切到該分支繼續(xù)開發(fā)可以加-f強(qiáng)制重置或者先創(chuàng)建一個(gè)新分支再切換git branch feature/bigred-optimize b2c3d4e git checkout feature/bigred-optimize這種做法相當(dāng)于把原來迷路的指針重新掛回了提交上。重建之后建議立刻核對(duì)提交內(nèi)容git log --oneline -n 5 git status git show --stat HEAD特別提醒重建分支前不要立即執(zhí)行g(shù)it gc或任何 prune 類命令否則可能提高恢復(fù)難度。3.3 用 git fsck 掃描懸空提交如果 reflog 里找不到相關(guān)提交說明記錄可能已經(jīng)被清理或過期此時(shí)可以嘗試用git fsck查找懸空對(duì)象。Git 對(duì)象分為提交對(duì)象、樹對(duì)象、數(shù)據(jù)對(duì)象等。一個(gè) commit 如果沒有任何分支或 Tag 指向它也沒有被 reflog 引用就會(huì)成為 unreachable 對(duì)象。可以使用以下命令查看git fsck --lost-found如果只想查看懸空提交可以加--unreachable配合 commit 類型過濾git fsck --full --no-reflogs --unreachable | grep commit輸出示例unreachable commit b2c3d4e... unreachable commit c3d4e5f...其中--no-reflogs表示不把 reflog 當(dāng)作可達(dá)引用這樣更容易找出那些同時(shí)失去 reflog 保護(hù)的對(duì)象。找到 commit 后可以先查看提交信息git show b2c3d4e如果確實(shí)是找回目標(biāo)同樣執(zhí)行g(shù)it branch feature/bigred-optimize b2c3d4e即可。需要明確的是git fsck并不是萬能藥如果之前執(zhí)行過git gc --prunenow且時(shí)間已經(jīng)很久對(duì)象可能已經(jīng)被物理刪除恢復(fù)概率會(huì)很低。3.4 找回后如何安全地把提交“帶出去”這里的“帶出去”不只是把分支切回來而是讓提交進(jìn)入安全、可發(fā)布的通道。找回提交后第一步是做完整性校驗(yàn)。建議比對(duì)代碼中是否包含預(yù)期的關(guān)鍵文件最好再執(zhí)行一次構(gòu)建或測(cè)試確認(rèn)這個(gè)提交是完整可用的。確認(rèn)無誤后立刻將分支推送到遠(yuǎn)端共享倉(cāng)庫(kù)這一步很關(guān)鍵git push -u origin feature/bigred-optimize推送后即使本地再次誤刪也能從origin/feature/bigred-optimize快速恢復(fù)。恢復(fù)方式很簡(jiǎn)單git fetch origin git checkout -b feature/bigred-optimize origin/feature/bigred-optimize到這里一次“找回 防再丟”的閉環(huán)操作就完成了。下一節(jié)會(huì)介紹為什么從開發(fā)第一天起就推遠(yuǎn)端、合并評(píng)審、打 Tag能夠從根源上避免這種“本地開發(fā)完卻帶不出去”的情況。4. 為什么需要一套能“帶出去”的分支發(fā)布流程4.1 核心流程從 feature 到遠(yuǎn)端備份很多開發(fā)事故的共同點(diǎn)是代碼只存在于本地分支遠(yuǎn)端沒有對(duì)應(yīng)備份。上一把“丟了的大紅”多半就是這樣丟的。為了杜絕這個(gè)場(chǎng)景團(tuán)隊(duì)?wèi)?yīng)該明確規(guī)定創(chuàng)建功能分支后第一次 commit 或者開始修改核心代碼之前就要先執(zhí)行一次推送。推薦的流程是這樣的從最新的 main 分支拉取基線創(chuàng)建本地功能分支。完成第一個(gè)有意義的 commit 后立即推送遠(yuǎn)端并設(shè)置上游關(guān)聯(lián)。后續(xù)每天至少推送一次或者每完成一個(gè)可運(yùn)行的小功能點(diǎn)推送一次。功能合并前確保遠(yuǎn)端分支與本地分支一致。合并到 main 分支后功能分支刪除與否都不影響代碼保留和安全發(fā)布。把“遠(yuǎn)端有備份”作為硬性要求能直接避免最危險(xiǎn)的單點(diǎn)故障。本地分支本質(zhì)上只是個(gè)人工作副本它不應(yīng)該成為關(guān)鍵提交的唯一存放位置。4.2 合并前統(tǒng)一提交規(guī)范commit message如果每次提交信息都是“更新”“修改”“bug fix”找回提交時(shí)會(huì)很難定位目標(biāo)。為提高可追溯性建議在團(tuán)隊(duì)內(nèi)約定一個(gè)精簡(jiǎn)的提交信息規(guī)范不必學(xué)大廠那么復(fù)雜但至少能看出模塊名和變更類型。例如feat(bigred): 增加訂單超時(shí)關(guān)閉能力 fix(bigred): 修復(fù)金額精度丟失 docs(bigred): 補(bǔ)充接口說明 refactor(bigred): 重構(gòu)優(yōu)惠計(jì)算邏輯 test(bigred): 增加單元測(cè)試當(dāng)你在 reflog 或 fsck 的輸出中檢索目標(biāo)時(shí)提交信息越清晰定位速度越快。實(shí)際操作時(shí)也可以配合git log --oneline --grepbigred搜索某個(gè)模塊相關(guān)的提交。這套習(xí)慣的收益并不僅僅在于“丟了容易找”更在于 code review、問題溯源和生產(chǎn)排障時(shí)能節(jié)省大量時(shí)間。4.3 發(fā)布分支與 Tag 管理功能開發(fā)完成后如果每次都把 main 分支最新代碼直接部署很容易出現(xiàn)“發(fā)布內(nèi)容不可控”的問題。更好的做法是基于 main 分支創(chuàng)建發(fā)布 Tag再用 Tag 標(biāo)記不可變的版本。普通開發(fā)流程可以用 squash merge 或普通 merge 把功能分支合入 main然后執(zhí)行g(shù)it checkout main git pull origin main git tag -a v1.4.0 -m release bigred optimize git push origin v1.4.0Tag 創(chuàng)建后建議不要通過git tag -d刪除再重建。如果一個(gè)版本已經(jīng)被測(cè)試、被發(fā)布系統(tǒng)記錄反復(fù)移動(dòng) Tag 會(huì)產(chǎn)生版本漂移最后你根本不知道生產(chǎn)環(huán)境上跑的代碼是哪一個(gè) commit。正確做法是一旦發(fā)現(xiàn) Tag 打錯(cuò)位置就放棄這個(gè) Tag打出新的遞增 Tag避免覆蓋。4.4 CI/CD 與制品備份讓產(chǎn)物不再丟上一把“丟了”的可能不只是代碼還包括構(gòu)建產(chǎn)物。如果發(fā)布流程是“開發(fā)在自己的電腦上構(gòu)建再把 jar/war 包傳到服務(wù)器”那么這個(gè)包很容易丟失別人也無從追溯包內(nèi)容。工程化的做法是把構(gòu)建過程交給 CI 系統(tǒng)構(gòu)建結(jié)果上傳到制品庫(kù)生產(chǎn)發(fā)布時(shí)只從制品庫(kù)拉取匹配版本。一個(gè)典型的 GitLab CI 流程可以表達(dá)為代碼推送 Tag 后觸發(fā)構(gòu)建構(gòu)建完成后生成鏡像或安裝包并上傳到制品平臺(tái)。下面給出一個(gè)示意性.gitlab-ci.yml主要用來展示思路實(shí)際字段需要根據(jù)你使用的 CI 系統(tǒng)調(diào)整stages: - build - push variables: APP_NAME: bigred-service IMAGE_TAG: $CI_COMMIT_TAG build: stage: build only: - tags script: - echo start build ${APP_NAME} - mvn clean package -DskipTests artifacts: paths: - target/*.jar push: stage: push only: - tags script: - echo upload artifact ${APP_NAME}:${IMAGE_TAG} # 這里替換為你的制品庫(kù)上傳命令在這個(gè)流程中CI 系統(tǒng)從 Tag 指向的固定 commit 構(gòu)建產(chǎn)物并把產(chǎn)物歸檔。即使本地分支被誤刪、本地構(gòu)建目錄被清理只要制品庫(kù)中還有歷史版本生產(chǎn)環(huán)境仍然可以拉起指定版本。5. 完整實(shí)戰(zhàn)讓“大紅”模塊安全發(fā)布一次5.1 創(chuàng)建 feature 分支并推送遠(yuǎn)端開始開發(fā)前先保證 main 分支最新git checkout main git pull origin main然后創(chuàng)建功能分支并推送git checkout -b feature/bigred-optimize git push -u origin feature/bigred-optimize推送之后可以在本地繼續(xù)開發(fā)。出現(xiàn)關(guān)鍵節(jié)點(diǎn)時(shí)先提交再推送git add . git commit -m feat(bigred): 完成優(yōu)惠計(jì)算重構(gòu) git push這里有一個(gè)小技巧提交時(shí)只添加本次修改相關(guān)文件不推薦無腦git add .。加入無關(guān)文件會(huì)讓提交歷史混亂找回時(shí)也難以判斷哪個(gè) commit 才對(duì)應(yīng) BigRed 模塊。5.2 模擬一次誤刪操作并找回現(xiàn)在我們模擬一次事故假設(shè)本地分支feature/bigred-optimize還沒被推送又不小心執(zhí)行了分支刪除操作git branch -D feature/bigred-optimize這時(shí)執(zhí)行g(shù)it branch已經(jīng)看不到該分支。但剛執(zhí)行完刪除reflog 里大概率仍有記錄。通過以下命令找回git reflog --dateiso | head -n 20找到類似moving from feature/bigred-optimize to main的那一行確認(rèn)它旁邊的 commit hash。然后重建分支git branch feature/bigred-optimize commit-hash git checkout feature/bigred-optimize為了保險(xiǎn)重建后立即推送遠(yuǎn)端git push -u origin feature/bigred-optimize此時(shí)分支已經(jīng)恢復(fù)到遠(yuǎn)端即使本地再刪一次也不會(huì)影響代碼安全。5.3 走合并評(píng)審流程分支開發(fā)并自測(cè)完成后不建議直接合并到 main。團(tuán)隊(duì)可以要求至少一次 Code Review由其他同事審查是否有明顯問題。這一步在 GitLab/GitHub 里通常對(duì)應(yīng) Merge Request 或 Pull Request。在評(píng)審?fù)ㄟ^后可以切換回 main 并執(zhí)行合并。如果想保留清晰的主干歷史推薦使用 squash mergegit checkout main git pull origin main git merge --squash feature/bigred-optimize git commit -m feat(bigred): 合并優(yōu)惠計(jì)算重構(gòu)到主分支 git push origin main如果團(tuán)隊(duì)更想保留功能分支的完整提交粒度也可以使用普通 mergegit merge --no-ff feature/bigred-optimize兩種方式各有優(yōu)缺點(diǎn)。對(duì)發(fā)布穩(wěn)定要求較高的項(xiàng)目我更推薦 squash merge因?yàn)樗茏?main 分支提交記錄保持線性、清晰回滾時(shí)只需要 revert 一個(gè) merge commit 即可。5.4 打 Tag 并觸發(fā)發(fā)布代碼合并到 main 后需要發(fā)布時(shí)創(chuàng)建 Taggit tag -a v1.4.0 -m release: bigred optimize git push origin v1.4.0在 CI 中配置好觸發(fā)規(guī)則后Tag 的推送會(huì)自動(dòng)觸發(fā)構(gòu)建。隨后去 CI 頁面確認(rèn)制品是否成功上傳。發(fā)布材料中應(yīng)該明確記錄以下信息發(fā)布版本號(hào)v1.4.0對(duì)應(yīng)的 commit hash制品倉(cāng)庫(kù)中的包名/鏡像名涉及哪些配置項(xiàng)變更這些信息越完整排查問題時(shí)越容易回溯。實(shí)際項(xiàng)目里一個(gè)常見的錯(cuò)誤是 Tag 打了但 CI 沒有觸發(fā)原因是觸發(fā)規(guī)則沒有允許 tags。這個(gè)不是 Git 本身的問題而是 CI 配置問題。需要重點(diǎn)檢查only: - tags或rules是否寫對(duì)了。5.5 發(fā)布失敗時(shí)回滾發(fā)布永遠(yuǎn)要考慮回滾方案。如果 v1.4.0 上線后出現(xiàn)嚴(yán)重問題最直接的回滾是在發(fā)布平臺(tái)上選擇上一個(gè)可用版本比如 v1.3.9 重新發(fā)布。使用 Tag 和制品庫(kù)的好處在于回滾不需要重新 checkout 代碼、不需要本地重新構(gòu)建直接用上一份制品即可。如果因?yàn)閿?shù)據(jù)庫(kù)兼容性問題導(dǎo)致無法快速回滾則需要執(zhí)行緊急修復(fù)在 main 上新建 hotfix 分支git checkout main -b hotfix/bigred-rollback # 修復(fù)問題并提交 git commit -m fix(bigred): 緊急回滾線上異常 git push -u origin hotfix/bigred-rollback修復(fù)驗(yàn)證通過后再合入 main 并打新的補(bǔ)丁版本 Tag。不建議通過修改歷史提交來解決線上問題因?yàn)槟菚?huì)讓版本內(nèi)容失真。6. 常見問題與排查清單6.1 常見錯(cuò)誤表格問題現(xiàn)象常見原因解決思路分支被誤刪reflog 中找不到記錄刪除已經(jīng)過去較長(zhǎng)時(shí)間或 reflog 被清理嘗試git fsck --full --no-reflogs --unreachablegit reset --hard后代碼丟失HEAD 指針被移動(dòng)到其他提交在 reflog 中找到原提交并重建分支未提交代碼被覆蓋沒有 commitreflog 不記錄工作區(qū)內(nèi)容優(yōu)先查看編輯器本地歷史或 IDE Local History本地分支從未推送且被 GC對(duì)象已物理清理恢復(fù)概率極低只能通過 IDE 緩存或同事副本處理分支刪了但遠(yuǎn)端還在只刪了本地分支通過git fetch直接從遠(yuǎn)端重建發(fā)布版本和代碼對(duì)不上Tag 被刪除重建避免覆蓋 Tag使用遞增 Tag生產(chǎn)環(huán)境拉不到制品未把構(gòu)建產(chǎn)物上傳制品庫(kù)引入 CI 構(gòu)件上傳步驟6.2 排查順序遇到“代碼不見了”的第一時(shí)間建議按以下順序排查先停止所有寫操作不執(zhí)行g(shù)it gc、git prune、git reset。執(zhí)行g(shù)it reflog只看 HEAD 移動(dòng)記錄。如果 reflog 沒有執(zhí)行g(shù)it fsck --full --no-reflogs --unreachable掃描懸空對(duì)象。根據(jù)提交信息、文件內(nèi)容、時(shí)間定位到目標(biāo) commit。用git branch重建分支。重建后先做本地構(gòu)建或測(cè)試驗(yàn)證。驗(yàn)證通過后立即推送到遠(yuǎn)端消除單點(diǎn)風(fēng)險(xiǎn)。這個(gè)順序可以避免很多二次傷害。因?yàn)橐坏┰趤G失狀態(tài)下繼續(xù)執(zhí)行破壞性操作原本能找回的對(duì)象可能真的被清理掉到時(shí)候后悔也就來不及了。7. 最佳實(shí)踐與工程建議7.1 提前配置 reflog 與回收策略不要等代碼丟了才想起 reflog。建議在團(tuán)隊(duì)新人入職的 Git 環(huán)境初始化文檔里給出下面這組配置讓 reflog 保留周期足夠覆蓋一次完整迭代git config --global gc.reflogExpire 180.days git config --global gc.reflogExpireUnreachable 30.days同時(shí)不建議在普通開發(fā)倉(cāng)庫(kù)中頻繁執(zhí)行g(shù)it gc或者帶有--prunenow的清理命令。清理對(duì)象庫(kù)的確能減小倉(cāng)庫(kù)體積但代價(jià)是丟失一次“后悔藥”。倉(cāng)庫(kù)體積問題更推薦用 Git LFS、子模塊或歸檔歷史等方式解決。7.2 分支命名與保護(hù)規(guī)則分支命名需要直觀體現(xiàn)業(yè)務(wù)含義推薦格式為type/module-summary例如feature/bigred-optimizefix/bigred-amounthotfix/payment-timeout在 GitLab 或 GitHub 中main 分支應(yīng)設(shè)置為受保護(hù)分支禁止普通成員直接 push。所有變更通過 Merge Request 合入并要求至少一名同事評(píng)審。這樣既能保證代碼質(zhì)量也能讓每一次合并都保留可追溯的評(píng)審記錄。7.3 備份、制品與審計(jì)發(fā)布過程不能只靠“本地電腦打包上傳”。工程上應(yīng)具備三個(gè)層次的保障源碼層所有 commit 都推送到遠(yuǎn)程 Git 倉(cāng)庫(kù)分支刪除也有 reflog 可以參考。制品層每次 CI/CD 構(gòu)建都會(huì)生成唯一可下載的制品并保留足夠長(zhǎng)的歷史周期方便回滾。審計(jì)層版本號(hào)、commit hash、制品編號(hào)、發(fā)布人與發(fā)布時(shí)間都記錄在發(fā)布表單或 CI 記錄中。這三個(gè)層次缺一不可。很多項(xiàng)目“上一把丟了大紅”表面看是 Git 分支誤刪除實(shí)際上卻是沒有制品備份和發(fā)布審計(jì)無法確定某個(gè)生產(chǎn)環(huán)境版本到底對(duì)應(yīng)哪段源碼。7.4 對(duì)“大紅丟了一次”這件事的復(fù)盤清單如果你正在處理一次已經(jīng)發(fā)生過的丟失事故可以用下面這個(gè)小清單去復(fù)盤當(dāng)前生產(chǎn)版本對(duì)應(yīng)哪個(gè) Tag 和 commit開發(fā)分支是否有遠(yuǎn)端備份本地是否有人保留了關(guān)鍵提交副本reflog 是否還有效能否定位最后一次提交能否從制品庫(kù)或 CI 緩存中恢復(fù)構(gòu)建產(chǎn)物找回后是否有代碼評(píng)審和驗(yàn)證后續(xù)發(fā)布流程是否需要調(diào)整否則會(huì)再次發(fā)生每一場(chǎng)事故都能暴露出流程里的薄弱點(diǎn)。能“帶出去”的代碼通常不是靠某一次臨時(shí)操作成功而是靠一套可依賴的流程托底。8. 總結(jié)從“上一把丟了大紅”到“這把總算是帶出去了”本質(zhì)上是開發(fā)習(xí)慣從“本地個(gè)人持有”轉(zhuǎn)變?yōu)椤斑h(yuǎn)端團(tuán)隊(duì)共享、CI 自動(dòng)構(gòu)建、制品留痕”的過程。本文完整演示了 Git 分支被誤刪后的恢復(fù)手段包括git reflog定位提交、git branch重建分支、git fsck掃描懸空對(duì)象以及找回后如何推送到遠(yuǎn)端避免再次丟失。同時(shí)也介紹了功能分支、Merge Request、Tag、CI/CD 和制品管理在發(fā)布鏈路中的作用。無論你負(fù)責(zé)的是服務(wù)端項(xiàng)目還是前端項(xiàng)目這套思路都適用。如果下次再遇到開發(fā)分支被誤刪不要慌。先執(zhí)行g(shù)it reflog找到最后一次提交的 hash然后重建分支并推送到遠(yuǎn)端。如果是未推送的本地提交且 reflog 已經(jīng)很久遠(yuǎn)再嘗試git fsck。真正要放在心上的不是某一次“救回來”的運(yùn)氣而是從項(xiàng)目第一天就設(shè)置遠(yuǎn)端備份、評(píng)審合并、固定版本發(fā)布這些防丟機(jī)制。這樣關(guān)鍵功能才能真正安全穩(wěn)定地“帶出去”。 Git分支丟失恢復(fù)指南：reflog與fsck找回誤刪提交的實(shí)操
很多開發(fā)團(tuán)隊(duì)其實(shí)都經(jīng)歷過類似場(chǎng)景一個(gè)重要功能已經(jīng)開發(fā)完成但因?yàn)榉种Ч芾聿灰?guī)范、提交沒有及時(shí)推送遠(yuǎn)端等到要發(fā)布時(shí)才發(fā)現(xiàn)本地倉(cāng)庫(kù)已經(jīng)被覆蓋或誤清理最后只能加班翻找、甚至返工。標(biāo)題里“上一把丟了的大紅這把總算是帶出去了”放在業(yè)務(wù)里看就是一個(gè)很典型的故事“大紅”是內(nèi)部負(fù)責(zé)的某個(gè)核心模塊上一輪開發(fā)時(shí)把它的變更弄丟了這一輪通過完善的分支策略和發(fā)布流程總算把功能安全地帶到了測(cè)試環(huán)境、生產(chǎn)環(huán)境。這篇文章不以閑聊為主而是依托這個(gè)場(chǎng)景完整梳理一套“Git 分支丟失后的找回操作 可實(shí)現(xiàn)安全交付的分支發(fā)布流程”。內(nèi)容會(huì)包括誤刪分支如何通過 reflog 和 fsck 找回、找回后怎么驗(yàn)證和恢復(fù)、如何避免再次出現(xiàn)同樣的問題以及從本地開發(fā)到制品發(fā)布的一整套工程化操作。無論你是剛接觸 Git 的新手還是需要規(guī)范交付流程的后端開發(fā)、測(cè)試同學(xué)都可以從這篇文章里找到直接能用的命令和方案。1. 先理解“丟了一把”到底丟的是什么1.1 “大紅”在這里指的是什么在真實(shí)項(xiàng)目中“大紅”大概率會(huì)是一個(gè)業(yè)務(wù)模塊的代號(hào)比如商城項(xiàng)目的訂單模塊、支付模塊、用戶積分模塊。為了敘述方便本文統(tǒng)一把目標(biāo)模塊稱為 BigRed在 Git 倉(cāng)庫(kù)中表現(xiàn)為一個(gè)功能分支例如feature/bigred-optimize。很多項(xiàng)目里的命名習(xí)慣并不統(tǒng)一有人用日期、有人用需求單號(hào)、有人用本地拼音縮寫。命名本身不是最要緊的最要緊的是這個(gè)分支上承載的代碼提交必須有且只有一個(gè)權(quán)威來源。上一把丟失的往往不是“代碼本身的字符”而是這些提交的引用關(guān)系。換句話說代碼對(duì)象可能還在 Git 對(duì)象庫(kù)里但我們已經(jīng)找不到指向它的分支指針了于是它成了“懸空提交”。所以先建立一個(gè)認(rèn)知在 Git 體系里“一個(gè)分支”本質(zhì)上只是一個(gè)可移動(dòng)的指針指針指向某一次 commit而 commit 又串聯(lián)出完整的提交歷史。分支被刪除時(shí)Git 只是刪除了這個(gè)指針并不會(huì)立刻物理刪除所有對(duì)象。明確這個(gè)概念對(duì)后續(xù)找回操作會(huì)非常有幫助。1.2 所謂“丟失”大多數(shù)情況不是代碼消失先說結(jié)論在大部分沒有執(zhí)行g(shù)it gc或?qū)ο笪幢磺謇淼那闆r下誤刪分支、git reset --hard之后的提交都依然殘留在.git目錄中。我們可以通過 Git 自帶的 reflog 機(jī)制把過去 HEAD 指針的移動(dòng)軌跡找出來再重新為對(duì)應(yīng)提交創(chuàng)建一個(gè)新分支。舉一個(gè)高頻發(fā)生的丟失場(chǎng)景開發(fā)者在feature/bigred-optimize分支上提交了好幾個(gè) commit但為了“保持本地干凈”某天執(zhí)行了git checkout master接著想重置當(dāng)前分支到遠(yuǎn)端狀態(tài)卻誤選了git reset --hard origin/master。這時(shí)本地分支的引用被強(qiáng)制移到了遠(yuǎn)端 master 的位置之前那幾個(gè) commit 就暫時(shí)“看不到”了。好在只要沒有觸發(fā)垃圾回收git reflog里還留著一長(zhǎng)串記錄。另一個(gè)高頻場(chǎng)景是執(zhí)行g(shù)it branch -D feature/bigred-optimize刪除了本地分支但該分支從未推送到遠(yuǎn)端遠(yuǎn)程origin/bigred-optimize不存在。這種情況相對(duì)危險(xiǎn)但依然有較高概率通過 HEAD 的 reflog 恢復(fù)。還有一種情況是完全未提交的代碼被覆蓋例如工作區(qū)修改還沒git commit直接執(zhí)行了git checkout .或git clean -fd。這種情況下未提交內(nèi)容基本不會(huì)出現(xiàn)在 reflog 中恢復(fù)成功率很低。所以文章后面會(huì)特別強(qiáng)調(diào)“小步提交 及時(shí)推送”的價(jià)值。1.3 這類問題的定位思路當(dāng)發(fā)現(xiàn)自己“把提交弄丟了”不要急著亂執(zhí)行命令先按照下面的順序做一次快速評(píng)估是否知道最后一次提交的 commit hash本地git reflog是否還能看到這條記錄遠(yuǎn)端是否曾經(jīng)存在對(duì)應(yīng)分支是否有人已經(jīng)拉取過這個(gè)分支并可能緩存了提交是否執(zhí)行過git gc或者長(zhǎng)時(shí)間沒有操作一旦明確當(dāng)前狀態(tài)就能選擇對(duì)應(yīng)的找回方案。后面第三節(jié)會(huì)給出具體命令但在此之前最好準(zhǔn)備一個(gè)干凈的環(huán)境來演練。下面先統(tǒng)一環(huán)境說明。2. 環(huán)境準(zhǔn)備與版本說明2.1 本地 Git 環(huán)境本文所有命令都基于 Git 命令行完成操作系統(tǒng)可以是 Windows、Linux 或 macOS。只要你的環(huán)境里已經(jīng)安裝 Git并能在終端執(zhí)行g(shù)it --version就可以繼續(xù)操作。git --version如果你還沒有配置用戶信息先做一次基礎(chǔ)設(shè)置git config --global user.name your-name git config --global user.email your-emailexample.com這里不強(qiáng)制指定 Git 的具體大版本因?yàn)?reflog、branch、fsck 等命令在 Git 2.x 版本中表現(xiàn)基本一致。如果你的項(xiàng)目使用的是老版本 Git建議先升級(jí)避免某些命令輸出格式不同。2.2 示例倉(cāng)庫(kù)與模塊命名為了演示我們可以在本地創(chuàng)建一個(gè)模擬倉(cāng)庫(kù)。倉(cāng)庫(kù)名定為demo-bigred-project里面模擬 BigRed 模塊的開發(fā)提交。后續(xù)的操作會(huì)展示如何創(chuàng)建分支、提交代碼然后模擬誤刪再執(zhí)行找回。mkdir demo-bigred-project cd demo-bigred-project git init這里先建立一條主分支提交作為項(xiàng)目基線git checkout -b main echo # Demo BigRed Project README.md git add README.md git commit -m docs: init project接下來創(chuàng)建 BigRed 模塊的功能分支并模擬開發(fā)git checkout -b feature/bigred-optimize mkdir -p src/main/java/com/example/bigred echo public class BigRedService {} src/main/java/com/example/bigred/BigRedService.java git add . git commit -m feat: init bigred service上述命令并不復(fù)雜但它模擬了真實(shí)開發(fā)里“工作從分支開始”的動(dòng)作。之所以強(qiáng)調(diào)分支而不是直接在 main 上開發(fā)是因?yàn)?main 分支通常承擔(dān)穩(wěn)定發(fā)布的責(zé)任不應(yīng)該塞入未驗(yàn)證的功能代碼。2.3 實(shí)驗(yàn)前準(zhǔn)備一份“可回退”的倉(cāng)庫(kù)找回類操作有一定風(fēng)險(xiǎn)尤其是當(dāng)你對(duì)倉(cāng)庫(kù)不熟悉時(shí)不要在重要的生產(chǎn)倉(cāng)庫(kù)上直接嘗試。更好的方式是把相關(guān)歷史先備份到一個(gè)獨(dú)立目錄cp -r demo-bigred-project /tmp/demo-bigred-project-backup或者使用 Git 自帶的 clone 方式備份git clone --mirror demo-bigred-project /tmp/demo-bigred-project.git.bak--mirror會(huì)克隆一個(gè)包含所有 refs 的裸倉(cāng)庫(kù)能覆蓋本地分支、遠(yuǎn)端分支、Tag 等引用信息。遇到重要倉(cāng)庫(kù)恢復(fù)場(chǎng)景先做鏡像備份是比較穩(wěn)妥的習(xí)慣。3. 找回誤刪分支與提交的核心操作3.1 用 git reflog 找回最近移動(dòng)過的提交git reflog是 Git 提供的一份“操作日志”它記錄 HEAD 指針在過去一段時(shí)間內(nèi)的移動(dòng)歷史。只要沒有手動(dòng)清理.git/logs尋找最近丟失的分支提交通常非常有效。在示例倉(cāng)庫(kù)中執(zhí)行g(shù)it reflog --dateiso輸出可能包含類似下面的記錄a1b2c3d HEAD{0}: checkout: moving from feature/bigred-optimize to main b2c3d4e HEAD{1}: commit: feat: init bigred service a1b2c3d HEAD{2}: checkout: moving from main to feature/bigred-optimize從實(shí)際經(jīng)驗(yàn)看reflog 的保留時(shí)間并不是無限長(zhǎng)。它和倉(cāng)庫(kù)的 gc 策略、提交數(shù)量、倉(cāng)庫(kù)使用頻率都有關(guān)默認(rèn)配置下通常能保留一段時(shí)間但如果你希望更穩(wěn)妥可以在全局或倉(cāng)庫(kù)級(jí)配置中適當(dāng)延長(zhǎng)保留周期。例如git config gc.reflogExpire 180.days git config gc.reflogExpireUnreachable 30.days上面第一條配置影響“仍然可達(dá)的 reflog 條目”的過期時(shí)間第二條影響“不可達(dá)條目”的過期時(shí)間。不同團(tuán)隊(duì)可以按提交頻率調(diào)整但要記得reflog 不是版本管理的備份工具它只是幫助你最后看一眼操作軌跡。3.2 用 git branch 重建分支當(dāng)通過 reflog 找到目標(biāo) commit hash 后重建分支只需要一條命令git branch feature/bigred-optimize commit-hash假設(shè)在 reflog 中看到的 BigRed 模塊提交 hash 是b2c3d4e那么執(zhí)行g(shù)it branch feature/bigred-optimize b2c3d4e如果想直接切到該分支繼續(xù)開發(fā)可以加-f強(qiáng)制重置或者先創(chuàng)建一個(gè)新分支再切換git branch feature/bigred-optimize b2c3d4e git checkout feature/bigred-optimize這種做法相當(dāng)于把原來迷路的指針重新掛回了提交上。重建之后建議立刻核對(duì)提交內(nèi)容git log --oneline -n 5 git status git show --stat HEAD特別提醒重建分支前不要立即執(zhí)行g(shù)it gc或任何 prune 類命令否則可能提高恢復(fù)難度。3.3 用 git fsck 掃描懸空提交如果 reflog 里找不到相關(guān)提交說明記錄可能已經(jīng)被清理或過期此時(shí)可以嘗試用git fsck查找懸空對(duì)象。Git 對(duì)象分為提交對(duì)象、樹對(duì)象、數(shù)據(jù)對(duì)象等。一個(gè) commit 如果沒有任何分支或 Tag 指向它也沒有被 reflog 引用就會(huì)成為 unreachable 對(duì)象。可以使用以下命令查看git fsck --lost-found如果只想查看懸空提交可以加--unreachable配合 commit 類型過濾git fsck --full --no-reflogs --unreachable | grep commit輸出示例unreachable commit b2c3d4e... unreachable commit c3d4e5f...其中--no-reflogs表示不把 reflog 當(dāng)作可達(dá)引用這樣更容易找出那些同時(shí)失去 reflog 保護(hù)的對(duì)象。找到 commit 后可以先查看提交信息git show b2c3d4e如果確實(shí)是找回目標(biāo)同樣執(zhí)行g(shù)it branch feature/bigred-optimize b2c3d4e即可。需要明確的是git fsck并不是萬能藥如果之前執(zhí)行過git gc --prunenow且時(shí)間已經(jīng)很久對(duì)象可能已經(jīng)被物理刪除恢復(fù)概率會(huì)很低。3.4 找回后如何安全地把提交“帶出去”這里的“帶出去”不只是把分支切回來而是讓提交進(jìn)入安全、可發(fā)布的通道。找回提交后第一步是做完整性校驗(yàn)。建議比對(duì)代碼中是否包含預(yù)期的關(guān)鍵文件最好再執(zhí)行一次構(gòu)建或測(cè)試確認(rèn)這個(gè)提交是完整可用的。確認(rèn)無誤后立刻將分支推送到遠(yuǎn)端共享倉(cāng)庫(kù)這一步很關(guān)鍵git push -u origin feature/bigred-optimize推送后即使本地再次誤刪也能從origin/feature/bigred-optimize快速恢復(fù)。恢復(fù)方式很簡(jiǎn)單git fetch origin git checkout -b feature/bigred-optimize origin/feature/bigred-optimize到這里一次“找回 防再丟”的閉環(huán)操作就完成了。下一節(jié)會(huì)介紹為什么從開發(fā)第一天起就推遠(yuǎn)端、合并評(píng)審、打 Tag能夠從根源上避免這種“本地開發(fā)完卻帶不出去”的情況。4. 為什么需要一套能“帶出去”的分支發(fā)布流程4.1 核心流程從 feature 到遠(yuǎn)端備份很多開發(fā)事故的共同點(diǎn)是代碼只存在于本地分支遠(yuǎn)端沒有對(duì)應(yīng)備份。上一把“丟了的大紅”多半就是這樣丟的。為了杜絕這個(gè)場(chǎng)景團(tuán)隊(duì)?wèi)?yīng)該明確規(guī)定創(chuàng)建功能分支后第一次 commit 或者開始修改核心代碼之前就要先執(zhí)行一次推送。推薦的流程是這樣的從最新的 main 分支拉取基線創(chuàng)建本地功能分支。完成第一個(gè)有意義的 commit 后立即推送遠(yuǎn)端并設(shè)置上游關(guān)聯(lián)。后續(xù)每天至少推送一次或者每完成一個(gè)可運(yùn)行的小功能點(diǎn)推送一次。功能合并前確保遠(yuǎn)端分支與本地分支一致。合并到 main 分支后功能分支刪除與否都不影響代碼保留和安全發(fā)布。把“遠(yuǎn)端有備份”作為硬性要求能直接避免最危險(xiǎn)的單點(diǎn)故障。本地分支本質(zhì)上只是個(gè)人工作副本它不應(yīng)該成為關(guān)鍵提交的唯一存放位置。4.2 合并前統(tǒng)一提交規(guī)范commit message如果每次提交信息都是“更新”“修改”“bug fix”找回提交時(shí)會(huì)很難定位目標(biāo)。為提高可追溯性建議在團(tuán)隊(duì)內(nèi)約定一個(gè)精簡(jiǎn)的提交信息規(guī)范不必學(xué)大廠那么復(fù)雜但至少能看出模塊名和變更類型。例如feat(bigred): 增加訂單超時(shí)關(guān)閉能力 fix(bigred): 修復(fù)金額精度丟失 docs(bigred): 補(bǔ)充接口說明 refactor(bigred): 重構(gòu)優(yōu)惠計(jì)算邏輯 test(bigred): 增加單元測(cè)試當(dāng)你在 reflog 或 fsck 的輸出中檢索目標(biāo)時(shí)提交信息越清晰定位速度越快。實(shí)際操作時(shí)也可以配合git log --oneline --grepbigred搜索某個(gè)模塊相關(guān)的提交。這套習(xí)慣的收益并不僅僅在于“丟了容易找”更在于 code review、問題溯源和生產(chǎn)排障時(shí)能節(jié)省大量時(shí)間。4.3 發(fā)布分支與 Tag 管理功能開發(fā)完成后如果每次都把 main 分支最新代碼直接部署很容易出現(xiàn)“發(fā)布內(nèi)容不可控”的問題。更好的做法是基于 main 分支創(chuàng)建發(fā)布 Tag再用 Tag 標(biāo)記不可變的版本。普通開發(fā)流程可以用 squash merge 或普通 merge 把功能分支合入 main然后執(zhí)行g(shù)it checkout main git pull origin main git tag -a v1.4.0 -m release bigred optimize git push origin v1.4.0Tag 創(chuàng)建后建議不要通過git tag -d刪除再重建。如果一個(gè)版本已經(jīng)被測(cè)試、被發(fā)布系統(tǒng)記錄反復(fù)移動(dòng) Tag 會(huì)產(chǎn)生版本漂移最后你根本不知道生產(chǎn)環(huán)境上跑的代碼是哪一個(gè) commit。正確做法是一旦發(fā)現(xiàn) Tag 打錯(cuò)位置就放棄這個(gè) Tag打出新的遞增 Tag避免覆蓋。4.4 CI/CD 與制品備份讓產(chǎn)物不再丟上一把“丟了”的可能不只是代碼還包括構(gòu)建產(chǎn)物。如果發(fā)布流程是“開發(fā)在自己的電腦上構(gòu)建再把 jar/war 包傳到服務(wù)器”那么這個(gè)包很容易丟失別人也無從追溯包內(nèi)容。工程化的做法是把構(gòu)建過程交給 CI 系統(tǒng)構(gòu)建結(jié)果上傳到制品庫(kù)生產(chǎn)發(fā)布時(shí)只從制品庫(kù)拉取匹配版本。一個(gè)典型的 GitLab CI 流程可以表達(dá)為代碼推送 Tag 后觸發(fā)構(gòu)建構(gòu)建完成后生成鏡像或安裝包并上傳到制品平臺(tái)。下面給出一個(gè)示意性.gitlab-ci.yml主要用來展示思路實(shí)際字段需要根據(jù)你使用的 CI 系統(tǒng)調(diào)整stages: - build - push variables: APP_NAME: bigred-service IMAGE_TAG: $CI_COMMIT_TAG build: stage: build only: - tags script: - echo start build ${APP_NAME} - mvn clean package -DskipTests artifacts: paths: - target/*.jar push: stage: push only: - tags script: - echo upload artifact ${APP_NAME}:${IMAGE_TAG} # 這里替換為你的制品庫(kù)上傳命令在這個(gè)流程中CI 系統(tǒng)從 Tag 指向的固定 commit 構(gòu)建產(chǎn)物并把產(chǎn)物歸檔。即使本地分支被誤刪、本地構(gòu)建目錄被清理只要制品庫(kù)中還有歷史版本生產(chǎn)環(huán)境仍然可以拉起指定版本。5. 完整實(shí)戰(zhàn)讓“大紅”模塊安全發(fā)布一次5.1 創(chuàng)建 feature 分支并推送遠(yuǎn)端開始開發(fā)前先保證 main 分支最新git checkout main git pull origin main然后創(chuàng)建功能分支并推送git checkout -b feature/bigred-optimize git push -u origin feature/bigred-optimize推送之后可以在本地繼續(xù)開發(fā)。出現(xiàn)關(guān)鍵節(jié)點(diǎn)時(shí)先提交再推送git add . git commit -m feat(bigred): 完成優(yōu)惠計(jì)算重構(gòu) git push這里有一個(gè)小技巧提交時(shí)只添加本次修改相關(guān)文件不推薦無腦git add .。加入無關(guān)文件會(huì)讓提交歷史混亂找回時(shí)也難以判斷哪個(gè) commit 才對(duì)應(yīng) BigRed 模塊。5.2 模擬一次誤刪操作并找回現(xiàn)在我們模擬一次事故假設(shè)本地分支feature/bigred-optimize還沒被推送又不小心執(zhí)行了分支刪除操作git branch -D feature/bigred-optimize這時(shí)執(zhí)行g(shù)it branch已經(jīng)看不到該分支。但剛執(zhí)行完刪除reflog 里大概率仍有記錄。通過以下命令找回git reflog --dateiso | head -n 20找到類似moving from feature/bigred-optimize to main的那一行確認(rèn)它旁邊的 commit hash。然后重建分支git branch feature/bigred-optimize commit-hash git checkout feature/bigred-optimize為了保險(xiǎn)重建后立即推送遠(yuǎn)端git push -u origin feature/bigred-optimize此時(shí)分支已經(jīng)恢復(fù)到遠(yuǎn)端即使本地再刪一次也不會(huì)影響代碼安全。5.3 走合并評(píng)審流程分支開發(fā)并自測(cè)完成后不建議直接合并到 main。團(tuán)隊(duì)可以要求至少一次 Code Review由其他同事審查是否有明顯問題。這一步在 GitLab/GitHub 里通常對(duì)應(yīng) Merge Request 或 Pull Request。在評(píng)審?fù)ㄟ^后可以切換回 main 并執(zhí)行合并。如果想保留清晰的主干歷史推薦使用 squash mergegit checkout main git pull origin main git merge --squash feature/bigred-optimize git commit -m feat(bigred): 合并優(yōu)惠計(jì)算重構(gòu)到主分支 git push origin main如果團(tuán)隊(duì)更想保留功能分支的完整提交粒度也可以使用普通 mergegit merge --no-ff feature/bigred-optimize兩種方式各有優(yōu)缺點(diǎn)。對(duì)發(fā)布穩(wěn)定要求較高的項(xiàng)目我更推薦 squash merge因?yàn)樗茏?main 分支提交記錄保持線性、清晰回滾時(shí)只需要 revert 一個(gè) merge commit 即可。5.4 打 Tag 并觸發(fā)發(fā)布代碼合并到 main 后需要發(fā)布時(shí)創(chuàng)建 Taggit tag -a v1.4.0 -m release: bigred optimize git push origin v1.4.0在 CI 中配置好觸發(fā)規(guī)則后Tag 的推送會(huì)自動(dòng)觸發(fā)構(gòu)建。隨后去 CI 頁面確認(rèn)制品是否成功上傳。發(fā)布材料中應(yīng)該明確記錄以下信息發(fā)布版本號(hào)v1.4.0對(duì)應(yīng)的 commit hash制品倉(cāng)庫(kù)中的包名/鏡像名涉及哪些配置項(xiàng)變更這些信息越完整排查問題時(shí)越容易回溯。實(shí)際項(xiàng)目里一個(gè)常見的錯(cuò)誤是 Tag 打了但 CI 沒有觸發(fā)原因是觸發(fā)規(guī)則沒有允許 tags。這個(gè)不是 Git 本身的問題而是 CI 配置問題。需要重點(diǎn)檢查only: - tags或rules是否寫對(duì)了。5.5 發(fā)布失敗時(shí)回滾發(fā)布永遠(yuǎn)要考慮回滾方案。如果 v1.4.0 上線后出現(xiàn)嚴(yán)重問題最直接的回滾是在發(fā)布平臺(tái)上選擇上一個(gè)可用版本比如 v1.3.9 重新發(fā)布。使用 Tag 和制品庫(kù)的好處在于回滾不需要重新 checkout 代碼、不需要本地重新構(gòu)建直接用上一份制品即可。如果因?yàn)閿?shù)據(jù)庫(kù)兼容性問題導(dǎo)致無法快速回滾則需要執(zhí)行緊急修復(fù)在 main 上新建 hotfix 分支git checkout main -b hotfix/bigred-rollback # 修復(fù)問題并提交 git commit -m fix(bigred): 緊急回滾線上異常 git push -u origin hotfix/bigred-rollback修復(fù)驗(yàn)證通過后再合入 main 并打新的補(bǔ)丁版本 Tag。不建議通過修改歷史提交來解決線上問題因?yàn)槟菚?huì)讓版本內(nèi)容失真。6. 常見問題與排查清單6.1 常見錯(cuò)誤表格問題現(xiàn)象常見原因解決思路分支被誤刪reflog 中找不到記錄刪除已經(jīng)過去較長(zhǎng)時(shí)間或 reflog 被清理嘗試git fsck --full --no-reflogs --unreachablegit reset --hard后代碼丟失HEAD 指針被移動(dòng)到其他提交在 reflog 中找到原提交并重建分支未提交代碼被覆蓋沒有 commitreflog 不記錄工作區(qū)內(nèi)容優(yōu)先查看編輯器本地歷史或 IDE Local History本地分支從未推送且被 GC對(duì)象已物理清理恢復(fù)概率極低只能通過 IDE 緩存或同事副本處理分支刪了但遠(yuǎn)端還在只刪了本地分支通過git fetch直接從遠(yuǎn)端重建發(fā)布版本和代碼對(duì)不上Tag 被刪除重建避免覆蓋 Tag使用遞增 Tag生產(chǎn)環(huán)境拉不到制品未把構(gòu)建產(chǎn)物上傳制品庫(kù)引入 CI 構(gòu)件上傳步驟6.2 排查順序遇到“代碼不見了”的第一時(shí)間建議按以下順序排查先停止所有寫操作不執(zhí)行g(shù)it gc、git prune、git reset。執(zhí)行g(shù)it reflog只看 HEAD 移動(dòng)記錄。如果 reflog 沒有執(zhí)行g(shù)it fsck --full --no-reflogs --unreachable掃描懸空對(duì)象。根據(jù)提交信息、文件內(nèi)容、時(shí)間定位到目標(biāo) commit。用git branch重建分支。重建后先做本地構(gòu)建或測(cè)試驗(yàn)證。驗(yàn)證通過后立即推送到遠(yuǎn)端消除單點(diǎn)風(fēng)險(xiǎn)。這個(gè)順序可以避免很多二次傷害。因?yàn)橐坏┰趤G失狀態(tài)下繼續(xù)執(zhí)行破壞性操作原本能找回的對(duì)象可能真的被清理掉到時(shí)候后悔也就來不及了。7. 最佳實(shí)踐與工程建議7.1 提前配置 reflog 與回收策略不要等代碼丟了才想起 reflog。建議在團(tuán)隊(duì)新人入職的 Git 環(huán)境初始化文檔里給出下面這組配置讓 reflog 保留周期足夠覆蓋一次完整迭代git config --global gc.reflogExpire 180.days git config --global gc.reflogExpireUnreachable 30.days同時(shí)不建議在普通開發(fā)倉(cāng)庫(kù)中頻繁執(zhí)行g(shù)it gc或者帶有--prunenow的清理命令。清理對(duì)象庫(kù)的確能減小倉(cāng)庫(kù)體積但代價(jià)是丟失一次“后悔藥”。倉(cāng)庫(kù)體積問題更推薦用 Git LFS、子模塊或歸檔歷史等方式解決。7.2 分支命名與保護(hù)規(guī)則分支命名需要直觀體現(xiàn)業(yè)務(wù)含義推薦格式為type/module-summary例如feature/bigred-optimizefix/bigred-amounthotfix/payment-timeout在 GitLab 或 GitHub 中main 分支應(yīng)設(shè)置為受保護(hù)分支禁止普通成員直接 push。所有變更通過 Merge Request 合入并要求至少一名同事評(píng)審。這樣既能保證代碼質(zhì)量也能讓每一次合并都保留可追溯的評(píng)審記錄。7.3 備份、制品與審計(jì)發(fā)布過程不能只靠“本地電腦打包上傳”。工程上應(yīng)具備三個(gè)層次的保障源碼層所有 commit 都推送到遠(yuǎn)程 Git 倉(cāng)庫(kù)分支刪除也有 reflog 可以參考。制品層每次 CI/CD 構(gòu)建都會(huì)生成唯一可下載的制品并保留足夠長(zhǎng)的歷史周期方便回滾。審計(jì)層版本號(hào)、commit hash、制品編號(hào)、發(fā)布人與發(fā)布時(shí)間都記錄在發(fā)布表單或 CI 記錄中。這三個(gè)層次缺一不可。很多項(xiàng)目“上一把丟了大紅”表面看是 Git 分支誤刪除實(shí)際上卻是沒有制品備份和發(fā)布審計(jì)無法確定某個(gè)生產(chǎn)環(huán)境版本到底對(duì)應(yīng)哪段源碼。7.4 對(duì)“大紅丟了一次”這件事的復(fù)盤清單如果你正在處理一次已經(jīng)發(fā)生過的丟失事故可以用下面這個(gè)小清單去復(fù)盤當(dāng)前生產(chǎn)版本對(duì)應(yīng)哪個(gè) Tag 和 commit開發(fā)分支是否有遠(yuǎn)端備份本地是否有人保留了關(guān)鍵提交副本reflog 是否還有效能否定位最后一次提交能否從制品庫(kù)或 CI 緩存中恢復(fù)構(gòu)建產(chǎn)物找回后是否有代碼評(píng)審和驗(yàn)證后續(xù)發(fā)布流程是否需要調(diào)整否則會(huì)再次發(fā)生每一場(chǎng)事故都能暴露出流程里的薄弱點(diǎn)。能“帶出去”的代碼通常不是靠某一次臨時(shí)操作成功而是靠一套可依賴的流程托底。8. 總結(jié)從“上一把丟了大紅”到“這把總算是帶出去了”本質(zhì)上是開發(fā)習(xí)慣從“本地個(gè)人持有”轉(zhuǎn)變?yōu)椤斑h(yuǎn)端團(tuán)隊(duì)共享、CI 自動(dòng)構(gòu)建、制品留痕”的過程。本文完整演示了 Git 分支被誤刪后的恢復(fù)手段包括git reflog定位提交、git branch重建分支、git fsck掃描懸空對(duì)象以及找回后如何推送到遠(yuǎn)端避免再次丟失。同時(shí)也介紹了功能分支、Merge Request、Tag、CI/CD 和制品管理在發(fā)布鏈路中的作用。無論你負(fù)責(zé)的是服務(wù)端項(xiàng)目還是前端項(xiàng)目這套思路都適用。如果下次再遇到開發(fā)分支被誤刪不要慌。先執(zhí)行g(shù)it reflog找到最后一次提交的 hash然后重建分支并推送到遠(yuǎn)端。如果是未推送的本地提交且 reflog 已經(jīng)很久遠(yuǎn)再嘗試git fsck。真正要放在心上的不是某一次“救回來”的運(yùn)氣而是從項(xiàng)目第一天就設(shè)置遠(yuǎn)端備份、評(píng)審合并、固定版本發(fā)布這些防丟機(jī)制。這樣關(guān)鍵功能才能真正安全穩(wěn)定地“帶出去”。