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