1. 為什么每個(gè)開(kāi)發(fā)者都要重新認(rèn)識(shí)Git如果你寫(xiě)過(guò)代碼大概率有過(guò)這樣的經(jīng)歷項(xiàng)目改到第三版想要找回昨天還能跑通的邏輯結(jié)果發(fā)現(xiàn)文件被覆蓋了或者團(tuán)隊(duì)幾個(gè)人同時(shí)改同一個(gè)文件互相發(fā)壓縮包最終分不清哪個(gè)是“最終版”。這些混亂本質(zhì)上都是因?yàn)闆](méi)有引入版本控制。而Git就是目前解決這個(gè)問(wèn)題最主流的工具。Git是分布式版本控制系統(tǒng)核心作用可以概括為三點(diǎn)記錄每一次文件變更、支持多分支并行開(kāi)發(fā)、實(shí)現(xiàn)多人協(xié)作時(shí)的版本合并與回溯。說(shuō)白了它像一個(gè)裝了時(shí)間機(jī)器的文件管理器——每個(gè)文件在什么時(shí)間被誰(shuí)改成了什么內(nèi)容全部留有痕跡隨時(shí)可以回到任意歷史節(jié)點(diǎn)。它不挑語(yǔ)言、不挑平臺(tái)無(wú)論你是寫(xiě)前端、后端、腳本還是處理文檔、配置、數(shù)據(jù)模型只要涉及文件變更管理都能用上。這篇文章適合所有接觸過(guò)命令行、但Git用得還比較零散的人。不管你是剛?cè)胄械男氯诉€是平時(shí)只點(diǎn)鼠標(biāo)、偶爾想系統(tǒng)化掌握Git的老手我會(huì)從最簡(jiǎn)單的高頻指令出發(fā)把每個(gè)命令背后的設(shè)計(jì)邏輯講清楚再給你一套可以照著敲的實(shí)操流程和踩坑記錄。文章不追求覆蓋Git所有冷門(mén)參數(shù)而是聚焦每天都會(huì)用到的那些指令讓你看完之后能在真實(shí)項(xiàng)目里直接上手。很多教程會(huì)把Git列成一長(zhǎng)串命令清單背完就忘。問(wèn)題不在于記不住參數(shù)而是不理解Git的底層模型。所以我會(huì)在講指令之前先講清楚Git的“三區(qū)”設(shè)計(jì)這是理解所有命令的鑰匙——只要你弄懂了文件在工作區(qū)、暫存區(qū)、版本庫(kù)之間怎么流動(dòng)后面幾乎每個(gè)命令都能順理成章地理解。2. Git核心設(shè)計(jì)思路為什么指令是長(zhǎng)這樣的2.1 三區(qū)模型工作區(qū)、暫存區(qū)、版本庫(kù)先不打命令先看一張心智模型。Git把項(xiàng)目目錄劃分成三個(gè)邏輯區(qū)域。第一個(gè)是工作區(qū)就是你電腦上肉眼能看到、用編輯器打開(kāi)修改的那些文件所在的位置。第二個(gè)是暫存區(qū)它是一個(gè)中間緩沖地帶運(yùn)行g(shù)it add后文件的快照會(huì)進(jìn)入這里但還沒(méi)有正式記錄到歷史中。第三個(gè)是版本庫(kù)也就是每次git commit之后文件快照被打包歸檔、形成不可變歷史記錄的地方。為什么要搞一個(gè)暫存區(qū)出來(lái)直接提交到版本庫(kù)不行嗎這恰恰是Git設(shè)計(jì)上很聰明的一點(diǎn)。它把“選擇改動(dòng)內(nèi)容”和“固化歷史”兩件事解耦了。比如你改了三個(gè)文件其中只有兩個(gè)是本次提交應(yīng)該包含的另一個(gè)是試驗(yàn)性修改還沒(méi)想好要不要。這時(shí)候可以先git add前兩個(gè)文件提交保留第三個(gè)文件在工作區(qū)繼續(xù)打磨。這就是暫存區(qū)存在的意義——讓提交的每個(gè)邏輯單元干干凈凈而不是把所有亂七八糟的改動(dòng)一股腦塞進(jìn)一次提交。還有一個(gè)細(xì)節(jié)值得注意git add暫存的是當(dāng)前文件內(nèi)容的“快照”而不是文件本身。也就是說(shuō)你git add了一個(gè)文件然后又做了修改這個(gè)新的修改并不會(huì)自動(dòng)進(jìn)入暫存區(qū)還需要再git add一次。很多新手在這里翻車——以為add過(guò)了就萬(wàn)事大吉結(jié)果提交后發(fā)現(xiàn)漏了最新改動(dòng)。理解了這個(gè)機(jī)制你就知道為什么Git會(huì)頻繁提示“Changes not staged for commit”。2.2 快照思維提交不是存差異而是存狀態(tài)另一個(gè)關(guān)鍵認(rèn)知是Git如何存儲(chǔ)數(shù)據(jù)。老牌工具SVN集中式版本控制記錄的是每次文件變更的差異補(bǔ)丁——第一版是完整文件第二版只存與第一版的差異第三版再存與第二版的差異。當(dāng)你要查看某個(gè)歷史版本時(shí)它需要沿著差異鏈一路重放越到后面越慢。而Git完全不同每次提交保存的是整個(gè)項(xiàng)目的“快照”——當(dāng)然不是每個(gè)文件復(fù)制一份而是用文件內(nèi)容做哈希校驗(yàn)內(nèi)容沒(méi)變的文件直接復(fù)用上一次的指針有變化的才存儲(chǔ)新版本。所以Git更像是在拍照每次commit都把當(dāng)前所有文件的狀態(tài)照一張相。你要回到哪張照片直接跳到那個(gè)節(jié)點(diǎn)就行不需要層層疊加計(jì)算。這種設(shè)計(jì)帶來(lái)兩個(gè)直接后果。第一Git幾乎可以在毫秒級(jí)完成任意歷史版本的回退和對(duì)比因?yàn)槊總€(gè)提交都是完整狀態(tài)。第二Git的幾乎所有操作都是在本地完成的——從歷史記錄查詢到分支切換都不需要網(wǎng)絡(luò)只有與遠(yuǎn)程倉(cāng)庫(kù)交互的指令需要網(wǎng)絡(luò)。這也是分布式版本控制最打動(dòng)人的地方即使在沒(méi)有服務(wù)器的環(huán)境下你的項(xiàng)目歷史和分支管理仍然可以完整運(yùn)轉(zhuǎn)。2.3 分支的本質(zhì)一個(gè)可移動(dòng)的指針?lè)种н@個(gè)概念很多人一開(kāi)始會(huì)覺(jué)得很玄。其實(shí)它的底層特別簡(jiǎn)單分支就是一個(gè)指向某個(gè)提交對(duì)象的“指針”特殊指針HEAD指向你當(dāng)前所在的提交。當(dāng)你創(chuàng)建新分支git branch feature時(shí)做的事情就是生成一個(gè)新的指針指向當(dāng)前HEAD所在的提交。當(dāng)你切換分支git checkout feature時(shí)做的事情就是把HEAD指針從master挪到feature上。每次提交當(dāng)前分支的指針往前移動(dòng)一步同時(shí)HEAD也跟著往前移。所以分支創(chuàng)建幾乎是零成本操作——它就只是一個(gè)指針副本哪怕你創(chuàng)建一百個(gè)分支代價(jià)也幾乎可以忽略不計(jì)。理解了分支是指針你就會(huì)明白為什么Git鼓勵(lì)多開(kāi)分支。因?yàn)榉种еg的切換成本極低你可以隨手開(kāi)一個(gè)實(shí)驗(yàn)分支去試方案不好用就刪掉對(duì)主分支毫無(wú)影響。這種低成本的試錯(cuò)能力是Git區(qū)別于老式版本工具的重要體驗(yàn)差異。3. Git常用指令拆解從高頻到進(jìn)階3.1 初始化與首次提交三連進(jìn)入一個(gè)新項(xiàng)目目錄第一件事是執(zhí)行g(shù)it init。這個(gè)命令會(huì)在當(dāng)前目錄下創(chuàng)建一個(gè)隱藏的.git文件夾里面存放Git的全部?jī)?nèi)部數(shù)據(jù)——你可以把它理解為“版本庫(kù)的數(shù)據(jù)庫(kù)”。緊接著建議執(zhí)行g(shù)it status這是開(kāi)發(fā)中最高頻的指令沒(méi)有之一。它會(huì)列出當(dāng)前工作區(qū)和暫存區(qū)的狀態(tài)哪些文件被修改了哪些已經(jīng)進(jìn)入暫存區(qū)哪些還沒(méi)被跟蹤。我的習(xí)慣是每做一次關(guān)鍵操作之后都跑一下git status確認(rèn)狀態(tài)符合預(yù)期再繼續(xù)這是一個(gè)非常好的習(xí)慣。首次提交的標(biāo)準(zhǔn)流程是這樣# 進(jìn)入項(xiàng)目目錄 cd my-project # 初始化倉(cāng)庫(kù) git init # 查看狀態(tài)此時(shí)所有文件都處于未跟蹤狀態(tài) git status # 把當(dāng)前目錄所有文件加入暫存區(qū) git add . # 再次查看狀態(tài)確認(rèn)暫存內(nèi)容 git status # 創(chuàng)建首次提交 git commit -m feat: initial commit這里有幾個(gè)細(xì)節(jié)值得展開(kāi)。git add .會(huì)添加當(dāng)前目錄下所有未跟蹤和被修改的文件但有一個(gè)例外——被.gitignore規(guī)則排除的文件不會(huì)被添加。.gitignore專門(mén)用來(lái)聲明哪些文件永遠(yuǎn)不該進(jìn)版本庫(kù)比如編譯產(chǎn)物、依賴包目錄node_modules、本地配置、日志文件等。這個(gè)文件應(yīng)該在項(xiàng)目一開(kāi)始就配好否則后面很容易把一堆沒(méi)用的文件提交進(jìn)倉(cāng)庫(kù)。git commit -m后面的消息不是隨便寫(xiě)的。規(guī)范的提交信息本身就是一種文檔資產(chǎn)良好的信息可以讓歷史記錄變成可閱讀的日志。業(yè)內(nèi)比較通用的簡(jiǎn)單寫(xiě)法是type: descriptiontype可以是feat新功能、fix修復(fù)、docs文檔、refactor重構(gòu)、chore雜務(wù)等。比如git commit -m fix: 修復(fù)登錄接口超時(shí)問(wèn)題一眼就能看出本次提交的目的。提交信息不規(guī)范回滾歷史的時(shí)候會(huì)非常痛苦你對(duì)著幾十條“update”根本不知道哪個(gè)是哪個(gè)。3.2 查看與對(duì)比log、diff、show提交記錄累計(jì)多了之后查看歷史用什么git log是最主要的命令。它按時(shí)間倒序列出所有提交記錄每行顯示提交哈希SHA-1、作者、日期和提交信息。# 查看完整提交歷史 git log # 查看簡(jiǎn)潔摘要一行一條 git log --oneline # 查看帶圖形化分支拓?fù)涞挠涗?git log --graph --oneline --allgit log --oneline是我用得最多的形式因?yàn)轫?xiàng)目大提交多的時(shí)候完整的log信息太長(zhǎng)一行一行的摘要足夠應(yīng)付絕大多數(shù)場(chǎng)景。--graph則能直觀看到分支分叉、合并的結(jié)構(gòu)特別是團(tuán)隊(duì)協(xié)作時(shí)非常有用。想在提交之前看看某個(gè)文件到底改了什么用git diff。# 查看工作區(qū)與暫存區(qū)的差異 git diff # 查看暫存區(qū)與上一個(gè)提交的差異 git diff --cached # 對(duì)比任意兩個(gè)提交之間的差異 git diff commit1 commit2git diff默認(rèn)對(duì)比的是工作區(qū)和暫存區(qū)的差異也就是你改了還沒(méi)add的部分。git diff --cached則對(duì)比暫存區(qū)和上一個(gè)提交也就是你add了還沒(méi)commit的部分。這兩個(gè)命令組合使用可以在提交前做到“心中有數(shù)”清楚地知道自己本次提交到底包含了哪些變更。如果只想看某一次提交的具體改動(dòng)內(nèi)容用git show# 查看最近一次提交改了什么 git show # 查看某次特定提交的改動(dòng) git show commit哈希這套組合拳擼下來(lái)你就能完全掌握“誰(shuí)在什么時(shí)候改了什么、為什么要改、改成了什么樣”這四件事。3.3 分支與合并branch、checkout、merge分支管理是Git高階操作的核心入口。# 列出所有本地分支當(dāng)前分支前有*號(hào) git branch # 基于當(dāng)前HEAD創(chuàng)建新分支 git branch feature-login # 切換分支 git checkout feature-login # 創(chuàng)建并切換分支等價(jià)于上面兩條合起來(lái) git checkout -b feature-login新版Git2.23引入了git switch來(lái)專門(mén)管理分支切換語(yǔ)義更清晰# 切換分支 git switch feature-login # 創(chuàng)建并切換 git switch -c feature-login我個(gè)人還是習(xí)慣用git checkout -b因?yàn)榧嫒菪院美蠙C(jī)器老教程都不會(huì)出問(wèn)題。但新項(xiàng)目里推薦用git switch語(yǔ)義更明確——checkout這個(gè)命令歷史上承擔(dān)了太多職責(zé)既要切換分支又要恢復(fù)文件初學(xué)者容易混淆。合并操作的核心指令是git merge# 先切換回接收方分支 git checkout master # 把功能分支合并進(jìn)來(lái) git merge feature-login要理解merge背后發(fā)生了什么事可以把它看成“三方合并”Git會(huì)找出兩個(gè)分支的共同祖先提交、當(dāng)前分支的提交、以及待合并分支的提交然后基于這三方狀態(tài)計(jì)算合并后的新快照。如果兩個(gè)分支修改的文件沒(méi)有重疊部分Git會(huì)自動(dòng)完成合并產(chǎn)生一個(gè)新的合并提交。如果改動(dòng)有沖突Git就會(huì)停下來(lái)把沖突標(biāo)記寫(xiě)在文件里要求你手動(dòng)處理。這個(gè)后面在問(wèn)題排查部分再展開(kāi)。合并之后功能分支就沒(méi)有存在必要了可以刪除git branch -d feature-login-d會(huì)檢查該分支是否已經(jīng)被合并如果還沒(méi)合并會(huì)拒絕刪除避免誤操作導(dǎo)致代碼丟失。如果你確實(shí)想拋棄一個(gè)分支的改動(dòng)用-D強(qiáng)制刪除。從這點(diǎn)也能看出Git的設(shè)計(jì)傾向——用規(guī)則保護(hù)歷史數(shù)據(jù)。3.4 遠(yuǎn)程協(xié)作clone、push、pull、fetch前面所有操作都是本地完成的但團(tuán)隊(duì)協(xié)作必然涉及遠(yuǎn)程倉(cāng)庫(kù)。常見(jiàn)的遠(yuǎn)程倉(cāng)庫(kù)平臺(tái)有很多GitHub、GitLab、Gitea等無(wú)論哪一個(gè)底層的Git指令都是一樣的。先介紹一個(gè)概念遠(yuǎn)程倉(cāng)庫(kù)在本地是一個(gè)“遠(yuǎn)程引用”默認(rèn)名字叫origin。它本質(zhì)上也只是個(gè)指針指向遠(yuǎn)程倉(cāng)庫(kù)的某個(gè)分支。要把遠(yuǎn)程項(xiàng)目拉下來(lái)用git clonegit clone https://example.com/group/project.git這條命令會(huì)自動(dòng)做幾件事創(chuàng)建同名目錄、初始化倉(cāng)庫(kù)、把遠(yuǎn)程的origin配置好、把默認(rèn)分支通常叫master或main拉到本地。也就是說(shuō)clone完成了從零到可開(kāi)發(fā)狀態(tài)的完整初始化。日常開(kāi)發(fā)中推送和拉取是最高頻的兩個(gè)遠(yuǎn)程操作# 推送本地分支到遠(yuǎn)程對(duì)應(yīng)分支 git push origin master # 拉取遠(yuǎn)程更新并合并到當(dāng)前分支 git pull origin master這里有一個(gè)核心區(qū)別需要注意git pull實(shí)際上是兩條命令的合體——git fetch加git merge。fetch只是把遠(yuǎn)程倉(cāng)庫(kù)的最新提交記錄下載到本地然后更新遠(yuǎn)程追蹤分支如origin/master但并不會(huì)改變你當(dāng)前分支的內(nèi)容。而merge才會(huì)把你本地分支和遠(yuǎn)程更新合并起來(lái)。如果只想查看遠(yuǎn)程更新、暫時(shí)不想合并就先執(zhí)行g(shù)it fetch觀察之后再做決定# 只下載遠(yuǎn)程更新不改變本地代碼 git fetch origin # 手動(dòng)合并遠(yuǎn)程更新到當(dāng)前分支 git merge origin/master這個(gè)拆分在日常協(xié)作里非常有用。比如你在本地改動(dòng)了一堆代碼還沒(méi)提交這時(shí)候同事推送了新更新。如果直接用git pull可能會(huì)因?yàn)閮蛇叾加懈膭?dòng)而引發(fā)沖突。你先git fetch看到更新內(nèi)容再?zèng)Q定是提交本地代碼后再合并還是先暫存本地修改再進(jìn)行合并——主動(dòng)權(quán)完全在自己手里。3.5 撤銷與回滾restore、reset、revert撤銷操作是Git里最容易產(chǎn)生誤解的部分也是新手踩坑重災(zāi)區(qū)。這里我按作用范圍分成三種場(chǎng)景。第一種工作區(qū)改了不該改的東西想丟棄改動(dòng)恢復(fù)成最近一次提交的內(nèi)容。# 丟棄工作區(qū)某個(gè)文件的未提交改動(dòng) git restore filename # 丟棄工作區(qū)所有未提交改動(dòng)慎用 git restore .第二種已經(jīng)add到了暫存區(qū)想取消暫存但保留文件改動(dòng)。git restore --staged filename這個(gè)命令等價(jià)于老版本里的git reset HEAD filename但現(xiàn)在語(yǔ)義更直觀--staged只操作暫存區(qū)不影響工作區(qū)文件。改動(dòng)不會(huì)丟只是從暫存區(qū)退出來(lái)。第三種已經(jīng)提交了但提交內(nèi)容有問(wèn)題想要回退歷史。這時(shí)有兩個(gè)方向取決于你如何處理歷史。如果想撤回一個(gè)已經(jīng)提交的改動(dòng)并保留歷史記錄用git revertgit revert commit哈希它會(huì)創(chuàng)建一個(gè)新的提交把指定提交的改動(dòng)反向應(yīng)用——相當(dāng)于“用一個(gè)新的提交來(lái)抵消舊的提交”。好處是歷史是直線前進(jìn)的適合多人協(xié)作倉(cāng)庫(kù)因?yàn)椴粫?huì)改寫(xiě)歷史、不會(huì)影響別人的克隆。如果還沒(méi)有推送或者這是一個(gè)完全個(gè)人使用的分支想直接拋棄最近的幾個(gè)提交用git reset# 軟回退提交記錄回到指定位置但工作區(qū)和暫存區(qū)內(nèi)容保留 git reset --soft commit哈希 # 混合回退提交記錄回退暫存區(qū)清空工作區(qū)內(nèi)容保留 git reset commit哈希 # 硬回退提交記錄、暫存區(qū)、工作區(qū)全部回退危險(xiǎn)操作 git reset --hard commit哈希我特別要提醒一句git reset --hard會(huì)讓你丟失指定提交之后的所有未提交改動(dòng)而且無(wú)法從本地恢復(fù)。如果這些改動(dòng)是重要的一定要在操作用做備份比如把當(dāng)前狀態(tài)先提交到一個(gè)臨時(shí)分支上。我的習(xí)慣是任何reset操作前先執(zhí)行一次git log --oneline確認(rèn)當(dāng)前哈希值心里列一下要回退哪些提交再動(dòng)手。4. 完整實(shí)操流程一個(gè)模擬項(xiàng)目從零到合并4.1 場(chǎng)景設(shè)定做一個(gè)帶登錄功能的網(wǎng)頁(yè)項(xiàng)目為了把這些指令串起來(lái)我模擬一個(gè)非常典型的開(kāi)發(fā)場(chǎng)景某團(tuán)隊(duì)目前有一個(gè)靜態(tài)網(wǎng)頁(yè)項(xiàng)目接下來(lái)要增加登錄頁(yè)面需要一個(gè)完整的功能開(kāi)發(fā)流程。你就跟著我的步驟在本地模擬整個(gè)操作。假設(shè)當(dāng)前項(xiàng)目已經(jīng)存在一個(gè)index.html和一個(gè)css/style.css。目標(biāo)開(kāi)發(fā)一個(gè)login.html登錄頁(yè)面完成后合并回主分支最后推送遠(yuǎn)程。整個(gè)流程的思維線是這樣主分支永遠(yuǎn)保持可發(fā)布狀態(tài)新功能在獨(dú)立分支開(kāi)發(fā)開(kāi)發(fā)測(cè)試通過(guò)后合并回主分支。這樣即使功能開(kāi)發(fā)一半崩了主分支上仍是可以發(fā)布的代碼。4.2 步驟一初始化倉(cāng)庫(kù)配置身份信息# 進(jìn)入項(xiàng)目目錄 cd my-webapp # 初始化 git init # 配置用戶名和郵箱提交記錄會(huì)帶上這些信息 git config user.name YourName git config user.email youexample.com注意git config有三層作用域。--system作用于整個(gè)操作系統(tǒng)所有用戶--global作用于當(dāng)前系統(tǒng)用戶的所有倉(cāng)庫(kù)--local只作用于當(dāng)前倉(cāng)庫(kù)。日常開(kāi)發(fā)建議至少設(shè)置--global級(jí)別的用戶名和郵箱這樣每個(gè)新倉(cāng)庫(kù)都不用重新配。但如果你參與多個(gè)團(tuán)隊(duì)不同項(xiàng)目的提交用戶名要區(qū)分開(kāi)可以在對(duì)應(yīng)倉(cāng)庫(kù)里用--local單獨(dú)覆蓋。4.3 步驟二首次提交建立基線# 查看當(dāng)前狀態(tài)確認(rèn)所有文件都是未跟蹤狀態(tài) git status # 編輯或創(chuàng)建.gitignore # 比如忽略臨時(shí)文件和日志*.log、tmp/ # 添加所有文件 git add . # 確認(rèn)一下哪些文件會(huì)被提交 git status # 創(chuàng)建首次提交 git commit -m feat: 初始化項(xiàng)目結(jié)構(gòu)第一次提交會(huì)被稱作“初始基線”所有后續(xù)改動(dòng)都基于它進(jìn)行。這里我強(qiáng)調(diào)一下查看git status的習(xí)慣——它不僅能告訴你哪些文件會(huì)被提交還會(huì)提示有沒(méi)有空目錄、超大文件等需要注意的內(nèi)容。很多代碼評(píng)審問(wèn)題其實(shí)在add階段就能提前發(fā)現(xiàn)。4.4 步驟三創(chuàng)建功能分支開(kāi)發(fā)登錄頁(yè)# 從當(dāng)前主分支創(chuàng)建并切換到feature分支 git checkout -b feature-login # 在分支上開(kāi)發(fā)創(chuàng)建login.html并修改樣式 # 這里執(zhí)行你的編輯器或IDE操作 # 查看哪些文件有變更 git status # 把新文件加入暫存區(qū) git add login.html css/ # 查看將要提交的內(nèi)容 git diff --cached # 提交登錄頁(yè)功能 git commit -m feat: 添加登錄頁(yè)面這里我想特別說(shuō)下為什么強(qiáng)調(diào)git diff --cached。你commit之前看一眼這個(gè)輸出會(huì)發(fā)現(xiàn)自己無(wú)意中多改了一些不該改的地方或者發(fā)現(xiàn)遺漏了某個(gè)功能文件。這一步能讓你少做很多“補(bǔ)救提交”。提交信息規(guī)范一點(diǎn)后續(xù)回滾、排錯(cuò)、評(píng)審都有章可循。4.5 步驟四回到主分支合并功能# 回到主分支 git checkout master # 拉取遠(yuǎn)程最新更新如果存在遠(yuǎn)程倉(cāng)庫(kù)防止覆蓋同事的提交 git pull origin master # 合并功能分支 git merge feature-login # 合并完成后刪除功能分支 git branch -d feature-login這一步在我的經(jīng)驗(yàn)中是最容易出狀況的。比如合并前沒(méi)有g(shù)it pull合并時(shí)才發(fā)現(xiàn)遠(yuǎn)程已經(jīng)更新了一大堆東西或者合并時(shí)發(fā)現(xiàn)改到了同一個(gè)文件的同一個(gè)區(qū)域觸發(fā)沖突。在合并之前養(yǎng)成“先同步再合并”的習(xí)慣能避開(kāi)大部分坑。假如合并時(shí)發(fā)生沖突Git會(huì)中止合并并在終端顯示沖突文件列表。需要手動(dòng)打開(kāi)文件搜索標(biāo)記找到?jīng)_突區(qū)域決定保留哪個(gè)版本或同時(shí)保留兩側(cè)代碼然后刪除標(biāo)記行保存文件。接著這樣操作# 把手動(dòng)解決后的文件標(biāo)記為已解決 git add 沖突文件 # 完成合并提交 git commitgit commit不帶-m的時(shí)候Git會(huì)打開(kāi)一個(gè)編輯器讓你輸入合并提交信息默認(rèn)消息已經(jīng)寫(xiě)好了直接保存退出即可。沖突不是可怕的事怕的是不去理解沖突內(nèi)容亂刪代碼。4.6 步驟五推送到遠(yuǎn)程倉(cāng)庫(kù)# 添加遠(yuǎn)程倉(cāng)庫(kù)地址首次推送前執(zhí)行一次 git remote add origin https://example.com/group/my-webapp.git # 推送分支到遠(yuǎn)程 git push -u origin master-u參數(shù)會(huì)把本地分支和遠(yuǎn)程分支關(guān)聯(lián)起來(lái)之后在這條分支上直接敲git push和git pull就可以省略遠(yuǎn)程名和分支名了。這個(gè)關(guān)聯(lián)關(guān)系是很多團(tuán)隊(duì)的開(kāi)發(fā)規(guī)范一部分方便日常操作。至此從零到完成一個(gè)功能開(kāi)發(fā)的完整流程已經(jīng)閉環(huán)。你會(huì)發(fā)現(xiàn)所有核心操作指令不超過(guò)十個(gè)日常開(kāi)發(fā)百分之八十的時(shí)間都在重復(fù)這套循環(huán)建分支、改代碼、提交、合并、推送。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 提交信息寫(xiě)錯(cuò)了怎么辦場(chǎng)景剛commit完發(fā)現(xiàn)信息里有個(gè)錯(cuò)別字或者想補(bǔ)充內(nèi)容。這時(shí)用git commit --amend可以修改最近一次提交的信息# 修改最近一次提交的信息 git commit --amend -m fix: 修正登錄超時(shí)校驗(yàn)邏輯這個(gè)操作會(huì)“替換”最近一次提交生成一個(gè)全新的提交哈希。如果這個(gè)提交已經(jīng)push到了遠(yuǎn)程再amend就會(huì)導(dǎo)致本地和遠(yuǎn)程歷史不一致下次push會(huì)被拒絕。這種情況要么強(qiáng)制推送git push --force但團(tuán)隊(duì)協(xié)作時(shí)不建議這樣做因?yàn)闀?huì)改寫(xiě)公共歷史、影響其他人的克隆倉(cāng)庫(kù)。所以--amend的安全使用場(chǎng)景是“提交之后發(fā)現(xiàn)有問(wèn)題但還沒(méi)推送”的時(shí)候。5.2 不小心把不該提交的文件提交了場(chǎng)景git add .手一抖把本地配置或日志文件也提交進(jìn)去了。解決思路先從版本控制中移除該文件但保留它在本地磁盤(pán)上。# 從Git追蹤中移除但保留文件 git rm --cached filename # 把這次移除提交 git commit -m chore: 移除誤提交的配置文件同時(shí)把該文件路徑加入.gitignore防止以后再次誤提交。要注意的是git rm --cached只是不再追蹤這個(gè)文件并不會(huì)把歷史記錄抹掉。如果那個(gè)文件包含密碼、密鑰之類的敏感信息僅僅刪除還不夠——信息已經(jīng)在歷史記錄里了需要考慮更徹底的清理方案或者直接聯(lián)系倉(cāng)庫(kù)管理員處理。這也提醒一點(diǎn)提交之前看清楚git status別把敏感文件帶進(jìn)去。5.3 合并沖突反復(fù)出現(xiàn)如何系統(tǒng)排查合并沖突的根源是同一個(gè)文件的同一個(gè)位置被兩個(gè)分支做了不同的修改。一旦發(fā)生沖突需要按下列順序處理第一步查看沖突文件列表git statusGit狀態(tài)欄下方會(huì)列出both modified的沖突文件。第二步打開(kāi)沖突文件看到這樣的標(biāo)記 HEAD 當(dāng)前分支的代碼 待合并分支的代碼 feature-loginHEAD指的是當(dāng)前分支的最新提交下方是待合并分支的代碼。需要你手動(dòng)選擇保留哪一邊或者把兩邊邏輯整合起來(lái)刪掉、、這些標(biāo)記行。第三步解決完所有沖突文件后逐一add然后commit完成合并。我的經(jīng)驗(yàn)是處理沖突前先看一遍兩個(gè)版本的上下文搞清楚各自的設(shè)計(jì)意圖再做取舍。如果兩個(gè)分支改的是不同邏輯單元沖突往往不大如果大面積重寫(xiě)了同一個(gè)模塊這時(shí)候最好拉上兩邊的人一起商量避免“合并完成但邏輯崩了”。另外合并前先跑一遍測(cè)試、做一次git diff查看改動(dòng)范圍能大大降低沖突發(fā)生的概率。5.4 想找回被reset誤刪的代碼場(chǎng)景用git reset --hard回退了后來(lái)發(fā)現(xiàn)回退后的某次提交里有一段代碼很重要想找回來(lái)。只要提交是“之前曾經(jīng)存在”的就有機(jī)會(huì)恢復(fù)。# 查看所有歷史操作記錄包括被reset拋棄的提交 git reflogreflog是Git的“操作日志”記錄了你本地每一條引用主要是分支和HEAD的每一次移動(dòng)。即使你reset之后某個(gè)提交不在任何分支上了reflog里仍然保留著它的哈希。找到那個(gè)哈希后直接切過(guò)去git checkout 哈?；蛘呋谠撎峤粍?chuàng)建新分支git branch recover-branch 哈希在本地倉(cāng)庫(kù)中reflog默認(rèn)保留30天足夠在誤操作后挽回大部分?jǐn)?shù)據(jù)。這里也再次印證了Git的底層設(shè)計(jì)是面向“數(shù)據(jù)安全”的只要你不主動(dòng)清垃圾數(shù)據(jù)大多時(shí)候都能救回來(lái)。6. 日常使用中的經(jīng)驗(yàn)心得這套指令用熟了之后有幾個(gè)心得我想額外分享。第一提交粒度盡量小。一次提交只做一個(gè)邏輯變更而不是“改了一堆東西消息寫(xiě)個(gè)update”。小的提交在代碼評(píng)審時(shí)更清晰、排錯(cuò)時(shí)能快速定位到具體環(huán)節(jié)、回滾時(shí)只影響局部不至于把所有改動(dòng)都帶回去。這個(gè)習(xí)慣越到項(xiàng)目后期越能看出價(jià)值。第二分支命名規(guī)范比分支數(shù)量重要。常見(jiàn)的命名方式包含類型、范圍、功能點(diǎn)比如feature/login、fix/avatar-upload、refactor/user-service。你過(guò)一個(gè)月的項(xiàng)目再回來(lái)看分支列表仍然是能看懂的。規(guī)范的命名也是一種團(tuán)隊(duì)資產(chǎn)。第三學(xué)會(huì)閱讀錯(cuò)誤提示。Git的命令行提示其實(shí)寫(xiě)得非常詳細(xì)比如push被拒時(shí)它會(huì)告訴你遠(yuǎn)程有更新、要先pullmerge沖突時(shí)會(huì)列出沖突文件清單。很多人出錯(cuò)以后的第一反應(yīng)是上網(wǎng)搜索其實(shí)先冷靜看一遍終端輸出大部分問(wèn)題都能自己解決。這個(gè)習(xí)慣用下來(lái)會(huì)感覺(jué)Git越用越順。Git的指令數(shù)量不算多高頻日常操作也就十幾個(gè)真正的門(mén)檻在于理解它背后的模型。把三區(qū)流動(dòng)、分支指針、快照存儲(chǔ)這幾個(gè)概念弄扎實(shí)后面不管遇到多復(fù)雜的操作無(wú)非是這幾個(gè)基本概念的不同組合而已。這幾年陸陸續(xù)續(xù)帶過(guò)一些新人發(fā)現(xiàn)只要在項(xiàng)目第一天把“工作區(qū)、暫存區(qū)、版本庫(kù)”這三個(gè)詞講透后面他們自己折騰Git的時(shí)候明顯更有底氣。在實(shí)際項(xiàng)目里養(yǎng)成一個(gè)固定節(jié)奏很有用開(kāi)工前先git pull同步最新開(kāi)發(fā)中經(jīng)常git status確認(rèn)狀態(tài)每次提交前git diff --cached檢查內(nèi)容合并分支前先同步再執(zhí)行。這套節(jié)奏看起來(lái)繁瑣但能規(guī)避掉大多數(shù)團(tuán)隊(duì)協(xié)作里讓人頭大的問(wèn)題。技術(shù)工具就是這樣——不是它多難而是你是否愿意在日?，嵥槔锊葴?zhǔn)每一個(gè)細(xì)節(jié)。