從第一次用git commit提交代碼到后來在團(tuán)隊(duì)項(xiàng)目里被一堆分叉的提交記錄弄得頭皮發(fā)麻我對(duì) Git 的態(tài)度經(jīng)歷了一個(gè)轉(zhuǎn)變它不只是“代碼版本的備份工具”更是一套能幫你把混亂的修改整理成清晰脈絡(luò)的方法論。很多人學(xué) Git 只停留在add、commit、push這三個(gè)命令上一旦遇到提交信息寫錯(cuò)、想合并幾個(gè)小修改、或者分支歷史亂成一團(tuán)就不知道該怎么辦了。今天這篇內(nèi)容就圍繞三個(gè)核心展開Git 基礎(chǔ)命令怎么用扎實(shí)、amend和rebase怎么用來整理提交記錄、以及日常開發(fā)里哪些圖形化工具能減輕心智負(fù)擔(dān)。無論你是剛開始接觸 Git 的新手還是已經(jīng)寫了一陣子代碼但一直被分支歷史困擾的開發(fā)者這篇都能給你一套可以直接落地的方法?，F(xiàn)在網(wǎng)上的 Git 教程很多但大部分要么只講命令行要么只講圖形界面很少有人把“命令行的思路”和“圖形化工具的操作”對(duì)應(yīng)起來講。我這幾年在多個(gè)團(tuán)隊(duì)、多個(gè)項(xiàng)目里折騰 Git踩過不少坑比如誤操作 rebase 導(dǎo)致提交丟失也曾經(jīng)在一個(gè)錯(cuò)誤提示面前卡了半天。所以今天的文章里除了命令用法還會(huì)穿插我自己的踩坑記錄和排查思路希望能讓你少走一些彎路。1. 環(huán)境搭建與基礎(chǔ)命令先把地基打牢1.1 安裝與全局配置不同系統(tǒng)的差異Git 的安裝在不同操作系統(tǒng)上差別不大但有幾個(gè)細(xì)節(jié)值得注意。Windows 上推薦從官網(wǎng)下載安裝包安裝時(shí)記得選 “Git Bash” 組件這樣你就有了一個(gè)類 Linux 的終端環(huán)境后面執(zhí)行命令時(shí)不會(huì)因?yàn)槁窂椒指舴麊栴}頭疼。macOS 上如果你裝了 Homebrew一條brew install git就行如果沒有 Homebrew直接裝 Xcode Command Line Tools 也可以它會(huì)自帶 Git。Linux 發(fā)行版就簡單了基于 Debian 或 Ubuntu 的系統(tǒng)直接apt install git基于 Red Hat 或 CentOS 的用yum install git。比如我之前在 Kali Linux 上折騰過一段時(shí)間那時(shí)也是sudo apt install git一條命令搞定。這里多說一句很多人覺得 Kali 就是用來做安全測試的其實(shí)它底層也是一個(gè)標(biāo)準(zhǔn) Linux 發(fā)行版Git 的用法和其他發(fā)行版沒有區(qū)別所以你在上面學(xué) Git 完全沒問題。安裝完成后第一件事不是建倉庫而是配置用戶名和郵箱。這一步特別容易被跳過但如果不配置你后續(xù)的提交記錄里會(huì)顯示一串奇怪的默認(rèn)用戶名而且團(tuán)隊(duì)協(xié)作時(shí)代碼提交人完全對(duì)不上。執(zhí)行下面兩條命令git config --global user.name 你的名字 git config --global user.email 你的郵箱這里用--global表示這臺(tái)機(jī)器上所有倉庫都用這個(gè)身份。如果某個(gè)項(xiàng)目需要特殊身份可以在倉庫目錄下不加--global重新設(shè)置一遍那就會(huì)覆蓋全局配置。你也可以用git config --list查看當(dāng)前生效的全部配置排查問題時(shí)會(huì)很有用。還要提一個(gè)容易踩坑的點(diǎn)換行符配置。Windows 和 Linux/macOS 的換行符不一樣如果團(tuán)隊(duì)里有人用 Windows 有人用 Linux不處理好的話每次提交都會(huì)顯示一堆無意義的修改。建議在 Windows 上設(shè)置git config --global core.autocrlf true在 Linux/macOS 上設(shè)置git config --global core.inputFile false或者統(tǒng)一在倉庫根目錄放一個(gè).gitattributes文件來規(guī)范。這個(gè)細(xì)節(jié)不是必須馬上處理但如果團(tuán)隊(duì)協(xié)作一段時(shí)間后出現(xiàn)“明明沒改代碼Git 卻提示大量文件有修改”的情況多半就是換行符引起的。1.2 第一次完整提交理解工作區(qū)、暫存區(qū)、版本庫Git 的日常操作可以簡化為一張流程圖工作區(qū)是你能看到的文件改動(dòng)暫存區(qū)是你用git add選中的改動(dòng)版本庫則是git commit之后保存下來的快照。剛接觸的人總喜歡把a(bǔ)dd和commit連在一起記但其實(shí)它們分別對(duì)應(yīng)兩個(gè)動(dòng)作add是告訴 Git “這些改動(dòng)我要了”commit是“把選中的改動(dòng)打包成一個(gè)版本”。一個(gè)典型的第一次提交流程是# 在項(xiàng)目根目錄初始化倉庫 git init # 查看當(dāng)前狀態(tài) git status # 把當(dāng)前目錄所有改動(dòng)加入暫存區(qū) git add . # 查看暫存區(qū)里的改動(dòng)詳情 git diff --cached # 提交并把提交信息寫清楚 git commit -m 初始化項(xiàng)目添加項(xiàng)目基礎(chǔ)結(jié)構(gòu)和說明文檔我見過很多人直接用git add .這個(gè)習(xí)慣本身沒問題但如果你新增了很多臨時(shí)文件比如編輯器生成的緩存、構(gòu)建產(chǎn)物它們也會(huì)被一股腦提交進(jìn)去。所以更嚴(yán)謹(jǐn)?shù)淖龇ㄊ窍仍陧?xiàng)目根目錄創(chuàng)建.gitignore文件把不需要跟蹤的內(nèi)容排除掉。比如 Python 項(xiàng)目要忽略__pycache__Node 項(xiàng)目要忽略node_modulesJava 項(xiàng)目要忽略target或build目錄。這樣git add .即使把當(dāng)前目錄全選了也不會(huì)把這些垃圾文件卷進(jìn)來。git status是整個(gè) Git 使用過程中最重要的命令。它告訴你當(dāng)前工作區(qū)干不干凈、暫存區(qū)有什么、哪些文件被修改了。很多人遇到問題第一反應(yīng)是去網(wǎng)上搜但我更建議你先敲一句git status它給出的提示往往已經(jīng)指明了下一步該怎么做。Git 的提示信息寫得很人性化有時(shí)候直接告訴你git add或git commit就能解決完全不用死記硬背。1.3 分支操作與合并為什么分支是 Git 的殺手锏分支是 Git 里最值得花時(shí)間理解的概念。簡單來說分支就是一個(gè)指向某個(gè)提交對(duì)象的可移動(dòng)指針。main或master是默認(rèn)分支你可以在它的基礎(chǔ)上拉出其他分支來開發(fā)新功能互不干擾。等到功能完成再把分支合并回去。最常用的分支命令有以下這些# 查看本地所有分支當(dāng)前分支前面會(huì)有 * 號(hào) git branch # 新建分支并同時(shí)切換過去 git checkout -b feature/login # 切換分支時(shí)工作區(qū)里未提交的改動(dòng)會(huì)跟著你走這會(huì)造成混亂務(wù)必先提交或暫存 git checkout main # 刪除本地分支 git branch -d feature/login切換到feature/login之后你可以正常修改文件、提交代碼。這些提交只出現(xiàn)在這個(gè)分支上不會(huì)影響main。等開發(fā)完畢切回main分支執(zhí)行g(shù)it merge feature/login把改動(dòng)合進(jìn)來。合并有兩種常見形態(tài)。一種是快進(jìn)合并fast-forward前提是main分支在你拉出feature/login之后沒有任何新的提交這種情況下 Git 直接把main指針移動(dòng)到feature/login的最新提交上非常干凈。另一種是三方合并也就是兩個(gè)分支各自都產(chǎn)生了新的提交Git 需要找一個(gè)共同的祖先提交然后把這個(gè)祖先提交和你當(dāng)前分支的修改、你要合并進(jìn)來的分支修改三者做拼合如果兩個(gè)分支對(duì)同一個(gè)文件的同一行都做了修改就會(huì)產(chǎn)生沖突。遇到?jīng)_突時(shí)Git 會(huì)在沖突文件里用、、標(biāo)記出不同分支的內(nèi)容你需要手動(dòng)決定保留哪些。處理完沖突后執(zhí)行g(shù)it add把沖突文件標(biāo)記為已解決然后繼續(xù)git merge或git commit完成合并。這里有一個(gè)實(shí)用習(xí)慣合并前先用git status確認(rèn)工作區(qū)是干凈的再用git diff main...feature/login預(yù)覽一下即將合并的內(nèi)容這樣能大幅降低合并沖突的驚嚇程度。2. 提交整理進(jìn)階amend 與 rebase 的核心用法2.1 git commit --amend修改最近一次提交的“后悔藥”git commit --amend的字面意思是“修改最近一次提交”。它不只是在提交信息里改幾個(gè)字那么簡單實(shí)際上它會(huì)用一個(gè)新的提交對(duì)象替換掉原來的提交對(duì)象所以如果你在修改之后還想保留原來的提交那是做不到的。具體用法有兩種場景。場景一提交信息寫錯(cuò)了。比如你剛提交完發(fā)現(xiàn)消息里有個(gè)拼寫錯(cuò)誤或者剛才寫的消息太籠統(tǒng)、完全看不出這次改了什么可以這樣做git commit --amend -m 修復(fù)登錄接口在空密碼時(shí)返回 500 的問題執(zhí)行完這條命令后原本的提交就被新提交替代了提交信息被改成正確的文件內(nèi)容不變。場景二提交時(shí)漏了文件或者文件修改后又想追加上去。比如你提交了一個(gè)新功能但忘了把某個(gè)測試文件加進(jìn)來可以這樣補(bǔ)救# 把漏掉的文件加入暫存區(qū) git add missing-file.txt # 連同新增文件一起修正最近一次提交 git commit --amend --no-edit--no-edit表示保留原有的提交信息不加這個(gè)參數(shù)的話Git 會(huì)打開編輯器讓你重新修改提交信息。我個(gè)人習(xí)慣用--no-edit因?yàn)檫@種場景下通常只是想補(bǔ)文件提交信息沒有變動(dòng)。這里必須重點(diǎn)提醒永遠(yuǎn)不要對(duì)你已經(jīng)推送到遠(yuǎn)程共享分支的提交執(zhí)行amend。因?yàn)槟阈薷牧颂峤粚?duì)象相當(dāng)于把這個(gè)提交的歷史重寫了別人如果已經(jīng)基于這個(gè)提交拉取了代碼他那邊就會(huì)和遠(yuǎn)程倉庫產(chǎn)生不一致后續(xù)pull或push時(shí)會(huì)非常痛苦。如果你的提交還沒有推送只是在本地那就可以放心大膽地使用。2.2 amend 的底層邏輯為什么說它是“新建提交”而不是“修改提交”我們通過git log看到的提交記錄每個(gè)提交都對(duì)應(yīng)一個(gè) SHA-1 哈希值。這個(gè)哈希值是根據(jù)提交內(nèi)容、提交信息、父提交哈希、作者時(shí)間等信息綜合計(jì)算出來的。也就是說只要你在amend過程中修改了提交信息或者追加了文件提交對(duì)象的哈希值就一定會(huì)變化。很多人以為amend是在原提交上打個(gè)補(bǔ)丁這個(gè)理解是錯(cuò)的。它實(shí)際上是 Git 把原提交從分支歷史中移除然后在相同位置插入一個(gè)全新的提交。原來提交的哈希會(huì)失效工作區(qū)內(nèi)容保持不變但你如果之前基于這個(gè)提交創(chuàng)建了其他分支那些分支的提交歷史里還會(huì)留著舊提交的引用到時(shí)候整理起來會(huì)很麻煩。理解了這一點(diǎn)你就明白為什么對(duì)已推送的提交執(zhí)行 amend 是危險(xiǎn)的你本地認(rèn)為“修正了歷史”但遠(yuǎn)程倉庫里仍然是舊的那個(gè)提交對(duì)象其他協(xié)作者也一直基于舊對(duì)象在上面繼續(xù)開發(fā)你一旦強(qiáng)制推送所有人的提交歷史都會(huì)亂掉。所以 amend 的安全使用邊界是只改那些還沒離開你電腦的提交。2.3 交互式 rebase用 rebase -i 把多個(gè)提交整理得井井有條git rebase的全稱是“變基”它的核心思想是把一個(gè)分支上的提交“重新放到”另一個(gè)分支的頂端。交互式變基git rebase -i則讓你在變基過程中重新組織提交的順序、合并多個(gè)提交、修改提交信息等是把雜亂無章的提交歷史整理干凈的最強(qiáng)工具。最常見的整理場景是你在一個(gè)功能分支上開發(fā)產(chǎn)生了五六個(gè)提交但有些提交只是“修正了一個(gè)錯(cuò)別字”“補(bǔ)充了一個(gè)注釋”這種細(xì)碎的提交放在歷史里特別影響閱讀。你可以用交互式變基把這些提交合并成一兩個(gè)有意義的提交。假設(shè)你要整理最近 3 個(gè)提交執(zhí)行g(shù)it rebase -i HEAD~3執(zhí)行后 Git 會(huì)打開一個(gè)文本編輯器列出最近 3 個(gè)提交每個(gè)提交前面有一個(gè)對(duì)應(yīng)操作的縮寫pick 1a2b3c4 修復(fù)登錄接口空密碼問題 pick 5d6e7f8 添加登錄接口測試用例 pick 9g0h1i2 修正測試用例中錯(cuò)誤的變量名這里最常用的操作是pick保留提交、reword修改提交信息、squash將該提交合并到前一個(gè)提交并保留兩個(gè)提交的信息、fixup將該提交合并到前一個(gè)提交丟棄當(dāng)前提交信息。如果你想把后面兩個(gè)細(xì)碎提交合并到第一個(gè)可以把第二行和第三行改成pick 1a2b3c4 修復(fù)登錄接口空密碼問題 squash 5d6e7f8 添加登錄接口測試用例 squash 9g0h1i2 修正測試用例中錯(cuò)誤的變量名保存退出后Git 會(huì)再次打開編輯器讓你填寫合并后的提交信息。兩個(gè)squash會(huì)把三個(gè)提交合并成一個(gè)最終只剩一個(gè)邏輯完整的提交。如果你只想保留第一個(gè)提交的信息可以把squash改成fixup這樣后面的提交信息會(huì)被直接丟棄操作更快。除了合并提交交互式 rebase 還能用來調(diào)整提交順序、刪除提交等。比如你把某一行的pick直接刪掉那個(gè)提交就會(huì)被移除。不過在刪除提交時(shí)一定要想清楚這個(gè)提交所包含的改動(dòng)是不是真的不需要了因?yàn)橐坏?rebase 完成被移除的提交就像從歷史上蒸發(fā)了一樣雖然可以用 reflog 找回但操作起來很麻煩。2.4 rebase 與 merge 的適用場景不是誰替代誰的關(guān)系很多新手容易糾結(jié)一個(gè)問題團(tuán)隊(duì)協(xié)作時(shí)到底用 rebase 還是 merge其實(shí)兩者解決的場景不同關(guān)鍵是看你想要什么樣的提交歷史。merge的特點(diǎn)是保留分支的分叉和合并記錄歷史里呈現(xiàn)出多個(gè)分支并行、最終交匯的形態(tài)。這種歷史是完整的、真實(shí)的適合在長期功能分支開發(fā)完成后的最終整合場景也適合在團(tuán)隊(duì)中作為主分支的常規(guī)合并方式。但缺點(diǎn)也很明顯如果分支特別多歷史會(huì)像葡萄藤一樣交叉纏繞閱讀起來很吃力。rebase的特點(diǎn)是把你的提交重新放到目標(biāo)分支的最頂端讓整個(gè)歷史看起來像是一條直線非常整潔。比如你在feature/login上開發(fā)執(zhí)行g(shù)it rebase main會(huì)把你的提交底基從原來的分叉點(diǎn)移動(dòng)到main的最新提交之上之后feature/login的歷史看起來就像是在main后面連續(xù)提交的。等合并進(jìn)main整個(gè)main歷史是線性的讀起來很舒服。但使用 rebase 也有代價(jià)從本質(zhì)上講它是在重寫歷史。如果你已經(jīng)把你的某個(gè)分支推送到了遠(yuǎn)程其他人也在用這個(gè)分支你擅自 rebase 然后強(qiáng)制推送會(huì)讓其他人的本地記錄和遠(yuǎn)程完全對(duì)不上。所以團(tuán)隊(duì)里如果要用 rebase必須約定清楚只允許在自己未推送或私有分支上執(zhí)行 rebase共享分支一律用 merge。我個(gè)人在本地開發(fā)時(shí)常用 rebase 來整理自己的提交但是推送到遠(yuǎn)程的共享分支之前一定會(huì)先git pull --rebase拉取最新代碼保證自己和遠(yuǎn)程是同步的然后再推送。這樣可以避免產(chǎn)生大量無意義的 merge commit。3. 常用圖形化工具助力從命令行到可視化3.1 圖形化工具的價(jià)值它到底解決什么問題命令行永遠(yuǎn)是 Git 最完整的操作方式但不可否認(rèn)有一些場景用圖形化工具效率會(huì)更高。比如查看分支結(jié)構(gòu)和提交歷史時(shí)命令行里只有一行行文本和縮進(jìn)符號(hào)主觀上很難快速理解整個(gè)項(xiàng)目的分叉情況而一個(gè)圖形化的提交樹能夠直接看到哪個(gè)分支領(lǐng)先、哪個(gè)分支落后、哪些提交是合并產(chǎn)生的一目了然。圖形化工具最適合的場景有三個(gè)一是倉庫結(jié)構(gòu)復(fù)雜分支多、提交多用圖形化界面審閱歷史比左一句git log --graph右一句git branch -v高效得多二是操作壓力大的動(dòng)作比如 rebase 過程中出現(xiàn)了沖突圖形化工具會(huì)把沖突文件列清楚并用可視化 diff 界面展示左右兩側(cè)的差異比在 vim 里看合并標(biāo)記直觀三是剛接觸 Git 的人圖形化工具能幫助建立“分支-提交-工作區(qū)”的心智模型從界面上看到暫存區(qū)、工作區(qū)和版本庫的關(guān)系概念理解起來快很多。當(dāng)然圖形化工具也有局限一些特殊操作比如復(fù)雜的歷史修改、子樹合并、濾除文件等在 GUI 上就沒有命令行那么直接。所以更推薦的做法是兩者結(jié)合日常操作或?qū)W習(xí)時(shí)用 GUI 觀察狀態(tài)遇到高手級(jí)操作或者腳本化批量處理時(shí)回到命令行。3.2 主流工具對(duì)比GitKraken、Sourcetree、Fork 和 IDE 自帶 Git目前市面上的 Git 圖形化工具非常多這里按使用場景給你挑幾個(gè)主流的作對(duì)比。工具平臺(tái)優(yōu)勢適用人群GitKrakenWindows/macOS/Linux基于 Electron界面漂亮提交樹渲染極好內(nèi)置 rebase 可視化操作支持多賬號(hào)管理想要高顏值、低門檻愿意接受商業(yè)訂閱的開發(fā)者SourcetreeWindows/macOS免費(fèi)Atlassian 出品支持貼片式 rebase 和交互式 rebase 的可視化操作使用 Bitbucket/GitLab 較多、喜歡免費(fèi)工具的開發(fā)者ForkWindows/macOS輕量、快diff 體驗(yàn)好支持命令行和 GUI 混用追求輕量高效、同時(shí)對(duì)節(jié)奏要求高的開發(fā)者VS Code 內(nèi)置 GitWindows/macOS/Linux不用另裝工具編輯器直接操作改動(dòng)、暫存、提交、推送用 VS Code 做主力編輯器、只需要基礎(chǔ)功能的開發(fā)者說實(shí)話我不建議新人一開始就花時(shí)間研究一堆 GUI 工具先掌握一個(gè)就夠了。我自己最常使用的是 VS Code 內(nèi)置的 Git 面板它可以直觀地查看工作區(qū)改動(dòng)、暫存文件、提交、推送還會(huì)顯示當(dāng)前分支狀態(tài)。遇到需要整理歷史時(shí)我會(huì)打開集成的終端執(zhí)行交互式 rebase畢竟復(fù)雜的 rebase 操作在 GUI 上反而容易看不清底層邏輯。如果你需要一個(gè)更專業(yè)的工具來查看提交樹我會(huì)更偏向 GitKraken 或 Fork因?yàn)樗鼈儗?duì)分支樹的渲染更清晰。特別是 GitKraken它有專門的可視化 rebase 面板可以拖動(dòng)提交節(jié)點(diǎn)放在不同的位置然后你甚至可以一邊看提交樹一邊思考這個(gè) rebase 是否合理。3.3 在圖形化工具中完成 amend 和 rebase以 VS Code 和 GitKraken 為例以 VS Code 自帶 Git 功能為例amend 操作可以通過命令面板實(shí)現(xiàn)。按CtrlShiftPmacOS 是CmdShiftP輸入 “Git: Commit (Amend)”然后會(huì)彈出輸入框讓你修改提交信息輸入新的提交信息后回車就和命令行g(shù)it commit --amend的效果一樣。這里有一個(gè)注意點(diǎn)如果你剛才已經(jīng)執(zhí)行了git add那么這些暫存的改動(dòng)也會(huì)一起被 amend 進(jìn)去所以如果你只打算修改提交信息、不打算包含新的改動(dòng)務(wù)必先檢查暫存區(qū)是否干凈。如果你使用 GitKrakenamend 就更直觀了選中要修改的提交右鍵選擇 “Amend” 或者在右側(cè)面板找到 “More Actions” 里的 “Amend”它會(huì)把當(dāng)前暫存區(qū)的改動(dòng)一并合并到這個(gè)提交里你可以直接編輯提交信息。rebase 在 GitKraken 里的操作也很貼心右鍵選中一個(gè)提交選擇 “Rebase this branch onto...” 然后指定目標(biāo)分支或者在左側(cè)分支列表直接拖拽某個(gè)分支到另一個(gè)分支的頂端實(shí)現(xiàn)變基。遇到?jīng)_突時(shí)GitKraken 會(huì)用顏色高亮沖突所在行并在右側(cè)面板里顯示可以解決沖突的文件列表你只需在編輯區(qū)完成修改然后回到 GitKraken 點(diǎn)擊 “Continue rebase” 即可。整體體驗(yàn)比在命令行里敲git rebase --continue再手動(dòng)處理要流暢得多。不過我必須提醒一句圖形化工具里的 rebase 操作往往會(huì)自動(dòng)添加--onto之類的參數(shù)如果你對(duì)底層邏輯不熟很容易點(diǎn)了幾下就覺得“這個(gè)提交怎么不見了”。我見過不止一個(gè)同事在 GUI 里誤點(diǎn) rebase 導(dǎo)致代碼丟失。在用任何圖形化工具做 rebase 之前先給你的分支創(chuàng)建一個(gè)備份分支比如git branch backup/rebase-test一旦強(qiáng)烈感覺不對(duì)勁馬上執(zhí)行g(shù)it reset --hard backup/rebase-test恢復(fù)原狀。4. 常見報(bào)錯(cuò)與疑難雜癥排查4.1 “You are in the middle of a cherry-pick — cannot amend” 到底怎么破這個(gè)報(bào)警信息在網(wǎng)絡(luò)熱詞里出現(xiàn)頻率很高很多人在執(zhí)行g(shù)it commit --amend時(shí)遇到它然后完全不知道發(fā)生了什么。它的意思是你當(dāng)前倉庫處于一個(gè) cherry-pick 操作進(jìn)行中的狀態(tài)Git 不允許你在這個(gè)狀態(tài)下 amend 提交。什么情況會(huì)觸發(fā) cherry-pick 狀態(tài)最常見的是你執(zhí)行了git cherry-pick commit-hash該操作嘗試把一個(gè)已經(jīng)存在的提交“復(fù)制”到當(dāng)前分支。如果復(fù)制過程中產(chǎn)生了沖突Git 會(huì)停下來等待你解決此時(shí)倉庫狀態(tài)就不是正常的分支提交狀態(tài)而是“cherry-pick 進(jìn)行中”的特殊狀態(tài)。在這個(gè)狀態(tài)下任何類似git commit --amend的操作都會(huì)被拒絕因?yàn)?Git 正在處理另一件尚未完成的事。解決辦法也很簡單先完成或中止下一個(gè)杏的 cherry-pick。如果你正在解決沖突就編輯文件、git add沖突文件然后執(zhí)行g(shù)it cherry-pick --continue如果你此時(shí)后悔了、不想要這個(gè) cherry-pick 了直接執(zhí)行g(shù)it cherry-pick --abort倉庫就會(huì)回到執(zhí)行前的狀態(tài)。等倉庫狀態(tài)恢復(fù)成正常的“無進(jìn)行中操作”狀態(tài)后你再執(zhí)行g(shù)it commit --amend就沒有任何問題了。還有一個(gè)小技巧當(dāng)遇到這種怪異報(bào)錯(cuò)時(shí)先執(zhí)行g(shù)it status看倉庫狀態(tài)描述。Git 的狀態(tài)提示里往往明確寫著“You are currently cherry-picking. (fix conflicts and run git cherry-pick --continue)”之類的提示。只要你按提示操作大概率能自己解決問題根本不用去搜索引擎里漫無目的地查。4.2 rebase 過程中沖突了怎么辦三條逃生路線rebase 過程中沖突比 merge 沖突更讓人焦慮因?yàn)楹芏嗳藫?dān)心搞砸了歷史。這里我給你三條逃生路線按安全系數(shù)從高到低排列第一只要沖突沒有復(fù)雜到你完全搞不定就繼續(xù)往前走。修改沖突文件、git add已解決的沖突、執(zhí)行g(shù)it rebase --continue。Git 會(huì)逐個(gè)提交地處理沖突每次處理完繼續(xù)直到整個(gè) rebase 完成。第二如果 rebase 進(jìn)行到一半你決定放棄直接執(zhí)行g(shù)it rebase --abort。這條命令會(huì)立刻停止 rebase 并把你帶回 rebase 開始之前的狀態(tài)所有修改和提交都會(huì)恢復(fù)到原來的位置。這是最安全的放棄方式什么都不用擔(dān)心。第三如果 rebase 已經(jīng)完成了但你發(fā)現(xiàn)有不對(duì)勁的地方比如某些改動(dòng)消失了別慌。Git 有個(gè)終極保底機(jī)制叫 reflog它記錄了你執(zhí)行過的所有 HEAD 變化包括 rebase 過程中的每一步。執(zhí)行g(shù)it reflog會(huì)看到一個(gè)操作歷史列表找到你想要回到的“那個(gè)提交”的哈希然后git reset --hard hash就可以跳回去。reflog 是本地操作日志不會(huì)被推送因此對(duì)個(gè)人恢復(fù)來說非?？煽俊＿@里要強(qiáng)調(diào)一個(gè)原則在 rebase 之前務(wù)必備一份當(dāng)前分支的狀態(tài)。在分支上提前執(zhí)行g(shù)it branch backup/分支名只是一個(gè)零成本的保險(xiǎn)卻能為你慌亂時(shí)節(jié)省大量時(shí)間。4.3 detached HEAD游離頭指針狀態(tài)為什么會(huì)丟失提交detached HEAD是新手經(jīng)常遇到的另一個(gè)怪異狀態(tài)。場景通常是執(zhí)行了git checkout commit-hash不帶分支名Git 會(huì)直接切換到一個(gè)匿名分支這個(gè)匿名分支只停留在你指定的那個(gè)提交上不指向任何分支命名。你在這個(gè)匿名分支上繼續(xù)提交了代碼但如果這時(shí)候你突然切換回main分支這些新提交就成了“孤兒”沒有任何分支指向它們。如果不小心它們很容易被 Git 的垃圾回收機(jī)制當(dāng)垃圾清掉。避免丟提交的最簡單辦法是一旦發(fā)現(xiàn)自己在 detached HEAD 狀態(tài)提交了代碼立刻執(zhí)行g(shù)it branch 新分支名把這個(gè)匿名提交綁定到一個(gè)新分支上。或者你在切換之前就先想清楚你到底是想查看歷史提交還是想在這個(gè)提交的基礎(chǔ)上做新開發(fā)如果是前者用git checkout -- file或git show hash更適合如果是后者直接git switch -c 新分支名 commit-hash創(chuàng)建基于該提交的分支絕不會(huì)進(jìn)入 detached HEAD。4.4 分支合并沖突排查不想手動(dòng)改文件先厘清沖突的邏輯合并沖突常見的幾種原因一定要心里有數(shù)兩個(gè)分支同時(shí)對(duì)同一個(gè)文件的同一行做了不同修改一個(gè)分支修改了文件某行另一個(gè)分支刪除了這個(gè)文件兩個(gè)分支同時(shí)新增了不同命名的關(guān)鍵文件導(dǎo)致各自的操作在合并時(shí)都要處理對(duì)方的內(nèi)容。這些情況都要靠人工判斷沒有“一鍵自動(dòng)解決沖突”的銀彈。面對(duì)沖突時(shí)我的常規(guī)步驟是這樣的執(zhí)行g(shù)it status查看沖突文件清單。逐個(gè)打開沖突文件努力理解兩個(gè)分支各自的意圖。如果修改的是代碼邏輯最好和相關(guān)負(fù)責(zé)人溝通確定最終保留哪份內(nèi)容、是否需要合成。編輯完沖突標(biāo)記后執(zhí)行g(shù)it add標(biāo)記為已解決。全部解決完畢后可以用git status確認(rèn)沒有沖突標(biāo)記了再執(zhí)行g(shù)it commit完成這次合并。如果你覺得自己合并得沒有把握用git diff --theirs -- OUR --THEIRS之類的參數(shù)分別查看兩個(gè)分支的版本差異或者干脆用圖形化工具打開沖突文件對(duì)比左右兩欄的內(nèi)容比在純文本里逐行讀標(biāo)記要舒服多了。這里還有個(gè)實(shí)用技巧當(dāng)發(fā)現(xiàn)某一份改動(dòng)已經(jīng)完全被另一份替代時(shí)直接用git checkout --ours/--theirs 文件路徑強(qiáng)制覆蓋成指定版本的整份文件可以省去手動(dòng)清理標(biāo)記的工作。報(bào)錯(cuò)或狀態(tài)常見原因解決方式Y(jié)ou are in the middle of a cherry-pick — cannot amendcherry-pick 過程中有沖突未解決處理沖突并git cherry-pick --continue或放棄操作git cherry-pick --abortfatal: Not possible to fast-forward當(dāng)前分支和上游分支分叉了先git pull --rebase或git merge再推送detached HEAD直接 checkout 了某個(gè) commit 而沒有指定分支用git switch -c 新分支名 hash創(chuàng)建分支或立刻給本地提交綁定新分支CONFLICT (content)兩個(gè)分支對(duì)同一文件的同一行做了不同修改手工會(huì)看邏輯并保留最終內(nèi)容然后 add 和 commitrebase 途中后悔rebase 進(jìn)行中產(chǎn)生了沖突執(zhí)行g(shù)it rebase --abort回到操作開始前這些情況我都經(jīng)歷過最焦慮的時(shí)刻往往不是報(bào)錯(cuò)本身而是不知道這個(gè)狀態(tài)會(huì)不會(huì)弄丟代碼?，F(xiàn)在我可以明確告訴你只要你在關(guān)鍵操作前備份分支、在不知所措時(shí)先看git status和git reflog大概率都能平安解決。最后分享一個(gè)小習(xí)慣我每次執(zhí)行rebase -i之前都會(huì)先git log --oneline --decorate -10看一眼自己的提交歷史確認(rèn)從哪個(gè) commit 開始整理再復(fù)制一份分支備份。整理完成后再用git log --oneline --decorate復(fù)查一遍歷史確保沒有遺漏或者誤刪。Git 的力量不全在于記住多少命令而在于你理解的模型夠不夠準(zhǔn)確、動(dòng)手之前有沒有先想清楚自己想要的歷史形態(tài)。希望這篇文章里講到的命令、工具和排查思路能讓你從“會(huì)用 Git”慢慢走向“能把 Git 用順手”。