做后端和前端一起聯(lián)調(diào)的時(shí)候最怕的不是代碼沖突而是“明明是一個(gè)項(xiàng)目大家卻在各自的分支里改出了平行宇宙”。尤其是團(tuán)隊(duì)一多、分支一亂今天你合并了別人的功能明天別人又把你剛剛修好的 bug 覆蓋了Git 歷史看起來像一團(tuán)毛線。這篇文章聊的就是 Git 多人協(xié)作的進(jìn)階場(chǎng)景不同分支下的并行開發(fā)。我會(huì)從分支模型設(shè)計(jì)、日常切換、合并策略、提交歷史整理、圖形化工具實(shí)操到高頻報(bào)錯(cuò)排查把真正用得上的細(xì)節(jié)和坑都攤開講適合剛接觸 Git 不久、但已經(jīng)在團(tuán)隊(duì)里被分支搞到頭大的同學(xué)。這一篇是系列的第二次分享上一篇主要講的是同一條分支上多個(gè)人怎么推拉同步這一篇的重點(diǎn)是“分支之間的協(xié)作”。你可以把它當(dāng)成一份實(shí)操筆記也可以直接按章節(jié)當(dāng)速查表來用。我盡量少講廢話多給能直接抄的步驟和命令也把我自己踩過的坑、試過之后覺得好用的習(xí)慣一并寫出來。1. 分支協(xié)作的核心設(shè)計(jì)先把規(guī)則定下來1.1 為什么“不同分支下的協(xié)作”比單純推拉復(fù)雜得多同一分支下的多人協(xié)作大家其實(shí)是一條流水線你推我拉按順序前進(jìn)就行。不同分支下就完全不一樣了每個(gè)人在自己的分支里改代碼最終要通過“合并”這個(gè)動(dòng)作把結(jié)果匯到一起。問題在于合并發(fā)生的時(shí)間點(diǎn)不可控你合并的時(shí)候別人的代碼可能已經(jīng)走了很遠(yuǎn)也可能正好改到了同一個(gè)文件的同一段邏輯。我見過不少團(tuán)隊(duì)初期完全沒有分支概念所有人都在 master 上干活功能上線全靠手動(dòng)挑代碼后來某次發(fā)布前發(fā)現(xiàn) master 已經(jīng)亂到?jīng)]人敢動(dòng)才老老實(shí)實(shí)開始用分支。這個(gè)過程的本質(zhì)其實(shí)是單分支只適合個(gè)人項(xiàng)目多人協(xié)作必須靠分支把“并行開發(fā)”和“最終整合”拆開。分支不是用來炫技的它是把團(tuán)隊(duì)的工作空間隔離出來的手段讓每個(gè)人在互不干擾的前提下干活最后再通過合并把大家的成果統(tǒng)一起來。隔離帶來了自由也帶來了成本。你不再直接看到別人的改動(dòng)所以代碼沖突的概率變高了你長時(shí)間不拉取遠(yuǎn)端本地分支會(huì)越來越“偏”合并時(shí)差異就會(huì)越來越大。所以不同分支下的協(xié)作核心不是命令記多少而是先掌握三個(gè)節(jié)奏分支怎么建、多久同步一次遠(yuǎn)端、合并前做什么檢查。1.2 常用的分支模型主干發(fā)布、功能分支與 Git Flow不同團(tuán)隊(duì)分支模型差異很大我見過最樸素的只有 master 和 dev 兩條分支也見過完整的 Git Flow 五層分支。選哪套不一定是越高大上越好而是看發(fā)布節(jié)奏和團(tuán)隊(duì)大小。下面是我實(shí)際對(duì)比下來比較有代表性的三套模型分支模型分支組成適用場(chǎng)景優(yōu)缺點(diǎn)主干發(fā)布型master/main 臨時(shí)分支小團(tuán)隊(duì)、持續(xù)發(fā)布簡單直接但功能之間互相影響大功能分支型master feature/* 分支中型團(tuán)隊(duì)、迭代明確隔離性好合并時(shí)集中處理沖突Git Flowmaster / develop / feature / release / hotfix多版本并行、需要嚴(yán)格發(fā)布管理結(jié)構(gòu)完整但流程較重小團(tuán)隊(duì)容易累我自己比較推薦中小團(tuán)隊(duì)用“功能分支型”每個(gè)功能從 master 拉一條 feature/xxx 分支開發(fā)完合并回 master合并后立刻刪除遠(yuǎn)端分支保持分支列表清爽。這套模式下分支數(shù)量可控也不容易出現(xiàn) hotfix 和 feature 之間的歷史糾纏。1.3 分支命名和提交信息的約定分支一多命名就是信息。我的習(xí)慣是feature/功能描述-編號(hào)比如feature/user-login-1024修復(fù)問題用hotfix/問題描述-編號(hào)比如hotfix/payment-timeout-2077。這樣別人在切換分支、看遠(yuǎn)端分支列表的時(shí)候一眼就知道這條分支要干嘛不用點(diǎn)開日志猜。提交信息同樣值得統(tǒng)一。團(tuán)隊(duì)里如果有人提交寫“fix bug”、有人寫“更新”、有人干脆不寫過兩周回看歷史基本等于看天書。建議簡單約定一個(gè)格式類型(范圍): 描述比如feat(user): 增加手機(jī)號(hào)登錄、fix(order): 修復(fù)重復(fù)支付提示。類型可以按 team 自己定常見的是 feat、fix、docs、refactor、test。這跟寫不寫代碼規(guī)范一樣不是強(qiáng)制但養(yǎng)成習(xí)慣后排查問題真的快很多。2. 多分支并行開發(fā)的日常操作切換、保存與同步2.1 切換分支前必須處理的工作區(qū)狀態(tài)不同分支下的協(xié)作最高頻的操作就是git switch老版本是git checkout。很多人第一次切分支就遇到報(bào)錯(cuò)“Your local changes would be overwritten by checkout”其實(shí)就是工作區(qū)里有改動(dòng)沒提交Git 怕切過去把你的本地修改覆蓋掉所以攔住了。我處理這種情況有一套固定動(dòng)作先git status看清楚當(dāng)前工作區(qū)到底改了什么如果是沒改完的半成品就用git stash暫存等切到目標(biāo)分支、干完手頭的事再切回來執(zhí)行g(shù)it stash pop。stash 相當(dāng)于把你的改動(dòng)放進(jìn)一個(gè)臨時(shí)的“口袋里”后續(xù)可以隨時(shí)取出來繼續(xù)改。有一點(diǎn)特別容易踩git stash pop并不是永遠(yuǎn)一帆風(fēng)順。如果在你 stash 之后這條分支本身也被別人改過并合并了那么 pop 的時(shí)候可能直接給你一個(gè)“CONFLICT”——又變成一次沖突處理。所以好的習(xí)慣是stash 前先記錄好自己改了哪幾個(gè)文件恢復(fù)沖突的時(shí)候心里才有數(shù)。不想用 stash 的另一種辦法是直接在當(dāng)前分支上新建一個(gè)臨時(shí)提交比如git commit -m wip: 臨時(shí)保存等后面整理歷史再通過git rebase -i合并。這招更適合你只是短暫切一下分支、馬上要回來繼續(xù)場(chǎng)景至少工作區(qū)是干凈的隨便切。2.2 同時(shí)維護(hù)多個(gè)本地分支的實(shí)用技巧worktree很多前端同學(xué)問過我一個(gè)問題同一個(gè)項(xiàng)目我同時(shí)在 vscode 里打開多個(gè)窗口一個(gè)窗口看 release 分支一個(gè)窗口開發(fā)新功能為什么這邊切分支那邊就變這是因?yàn)橥粋€(gè)工作目錄在一個(gè)時(shí)刻只能檢出一個(gè)分支。你在一個(gè)目錄里切換分支等于把它整個(gè)目錄下的代碼換成另一個(gè)狀態(tài)。想要同時(shí)讓多個(gè)分支的代碼并行存在可以用git worktree。它允許你在額外目錄里再檢出一個(gè)分支出來比如我現(xiàn)在主目錄在 develop 分支同時(shí)我又想改 release 分支上的一個(gè)緊急問題就執(zhí)行g(shù)it worktree add ../myproject-release release這樣myproject-release目錄下就是 release 分支的完整代碼兩個(gè)目錄互不干擾vscode 直接開兩個(gè)窗口分別打開即可。實(shí)測(cè)下來這個(gè)功能非常穩(wěn)是處理“同項(xiàng)目多分支同時(shí)開發(fā)”的官方方案。需要注意的是同一個(gè)分支不能在多個(gè) worktree 里同時(shí)檢出這是 Git 的硬性限制。而且加了 worktree 之后后續(xù)如果不想用了要在主目錄執(zhí)行g(shù)it worktree remove ../myproject-release不能直接手刪目錄否則會(huì)留下管理記錄。2.3 拉取遠(yuǎn)端分支與保持本地分支同步在多人協(xié)作場(chǎng)景下每天開工后的第一件事我建議是git fetch而不是直接git pull。fetch只把遠(yuǎn)端更新拉到本地“遠(yuǎn)端跟蹤分支”不會(huì)動(dòng)你當(dāng)前工作區(qū)pull等于fetch merge它直接會(huì)改變你的工作區(qū)。如果你在本地要為別人剛創(chuàng)建的功能分支建一個(gè)對(duì)應(yīng)的本地分支最保險(xiǎn)的方式是git fetch origin git checkout -b feature/user-login origin/feature/user-login這樣本地分支會(huì)直接跟蹤遠(yuǎn)端分支后續(xù)git pull和git push都會(huì)自動(dòng)關(guān)聯(lián)不用每次加參數(shù)。在實(shí)際工作里保持同步頻率很重要。我見過太多人一條分支干兩三個(gè)星期期間從不 pull最后合并的時(shí)候差異大到?jīng)_突鋪滿屏幕光解決沖突就花掉大半天。比較好的節(jié)奏是功能分支每完成一個(gè)小步驟就 push 一次遠(yuǎn)端每個(gè)工作日至少 fetch 一兩次如果發(fā)現(xiàn)自己分支和主干差得越來越遠(yuǎn)盡早處理越拖越痛。3. 分支合并merge、rebase 與 cherry-pick 的取舍3.1 merge 和 rebase 怎么選優(yōu)先級(jí)是什么分支開發(fā)的最終動(dòng)作就是合并。Git 合并有兩種主要方式git merge和git rebase。它們的結(jié)果差別很大團(tuán)隊(duì)協(xié)作中必須有個(gè)統(tǒng)一偏好否則歷史會(huì)非常亂。merge 的特點(diǎn)是“保留真實(shí)”它會(huì)把兩條分支的異動(dòng)合并成一個(gè)新的合并提交歷史里能清楚看到哪幾個(gè)分支匯合了。rebase 的特點(diǎn)是“重放”它把當(dāng)前分支的提交一個(gè)個(gè)摘下來接到目標(biāo)分支的最新提交后面形成一條線性歷史。從可讀性上看rebase 出來的歷史干凈得多但從安全性上看rebase 會(huì)重寫提交 ID不適合對(duì)已經(jīng)推送到遠(yuǎn)端的共享分支操作。我的使用建議非常明確功能分支合并回主干使用git merge必要時(shí)加--no-ff保留合并節(jié)點(diǎn)。功能分支同步主干最新代碼優(yōu)先用git rebase避免產(chǎn)生無意義的合并節(jié)點(diǎn)。已經(jīng) push 到遠(yuǎn)端、且別人可能也在用的分支絕不隨便 rebase。這里特別推薦一個(gè)習(xí)慣合并功能分支時(shí)用git merge --no-ff feature/xxx。就算功能分支落后--no-ff也會(huì)保留一個(gè)明確的合并提交線上回滾時(shí)一眼就能看到“這次上線包含了哪幾個(gè)合并”而不會(huì)把提交全部快進(jìn)成一條看不見邊界的線。3.2 沖突處理實(shí)操從看懂標(biāo)記到完成合并沖突永遠(yuǎn)無法完全避免但能通過流程把它降到最低。一旦出現(xiàn)沖突Git 會(huì)在文件里寫入沖突標(biāo)記長這樣 HEAD 當(dāng)前分支的這一段代碼 被合并分支的這一段代碼 feature/user-login下面的部分是你當(dāng)前分支的代碼下面是待合并分支的代碼。你要做的不是選一邊或者兩邊都保留而是理解這兩段代碼分別想干什么然后寫出正確的整合結(jié)果再把沖突標(biāo)記全部刪干凈。我處理沖突的固定流程是打開沖突文件逐個(gè)看完沖突段。如果這段邏輯比較復(fù)雜去問另一條分支的負(fù)責(zé)人“這句話為什么這么改”不要自己硬猜。改成正確代碼后保存文件執(zhí)行g(shù)it add file標(biāo)記為已解決。全部解決后執(zhí)行g(shù)it commitmerge 會(huì)默認(rèn)生成合并提交信息。很多人栽在沖突排查上是因?yàn)闆]有看全。這里分享一個(gè)命令git diff --name-only --diff-filterU可以列出所有處于沖突狀態(tài)的文件配合git mergetool還能調(diào)起可視化對(duì)比工具。我建議每次都把“沖突文件列表”完整過一遍再接下一步寧可多看一眼也別提交漏了。3.3 把其他分支的某部分功能遷過來cherry-pick 的實(shí)戰(zhàn)用法工作中經(jīng)常會(huì)遇到這種場(chǎng)景feature/A 做了一堆功能但其中有一個(gè)小改動(dòng)比如修了個(gè)公共方法feature/B 現(xiàn)在就要用?？偛荒茏?B 把整個(gè) A 合并過來那樣會(huì)把還沒準(zhǔn)備好的功能全部拖進(jìn)來。這時(shí)候就該用git cherry-pick它的作用是把某條分支上的指定提交提取出來放到當(dāng)前分支上重放一次。使用方法很簡單git checkout feature/B git cherry-pick a1b2c3d4a1b2c3d4是你在 feature/A 分支上看git log拿到的提交哈希。如果功能由多個(gè)提交組成可以一次拿一段范圍git cherry-pick a1b2c3d4..e5f6a7b8這里的范圍是左開右閉也就是不包含a1b2c3d4這個(gè)提交。想連第一個(gè)也一起拿就用git cherry-pick a1b2c3d4^..e5f6a7b8。cherry-pick 同樣可能沖突解決方案和 merge 沖突一樣解決后git cherry-pick --continue即可。我自己的經(jīng)驗(yàn)是能整條分支合并就別用 cherry-pick能用 cherry-pick 就別手動(dòng)復(fù)制粘貼代碼。手動(dòng)復(fù)制大段代碼是最危險(xiǎn)的做法因?yàn)閬G失上下文和提交記錄后后續(xù)追查問題會(huì)非常痛苦。4. 提交歷史整理與分支清理讓 Git 日志保持可讀4.1 修改最近一次提交commit --amend 的正確姿勢(shì)很多人在剛提交完就發(fā)現(xiàn)少了一個(gè)文件、或者提交信息寫錯(cuò)了。不需要再補(bǔ)一個(gè)“fix: 補(bǔ)充”的垃圾提交直接用git commit --amend修改上一次提交即可。git add 忘記加的文件 git commit --amend -m feat(user): 增加手機(jī)號(hào)登錄注意amend 實(shí)際上是把當(dāng)前提交替換成一個(gè)全新提交提交 ID 會(huì)變化。所以這條命令只適合還沒有 push 到遠(yuǎn)端共享分支的提交。如果已經(jīng) push 了且別人已經(jīng)基于它繼續(xù)開發(fā)那最好不要 amend實(shí)在要改就得git push --force-with-lease強(qiáng)推但這對(duì)其他人影響很大屬于萬不得已的操作。--force-with-lease比--force更安全簡單說就是它會(huì)檢查遠(yuǎn)端有沒有別人更新如果遠(yuǎn)端變了會(huì)拒絕強(qiáng)推。這里順手提一句任何情況下的強(qiáng)推都要謹(jǐn)慎它會(huì)讓遠(yuǎn)端的提交歷史“消失”別人如果沒來得及拉取可能直接崩掉。4.2 多個(gè)提交需要整理時(shí)rebase -i 的用途如果想改的不是最后一次提交而是最近幾個(gè)提交比如想把三個(gè)小提交合并成一個(gè)完整的提交或者想把某個(gè)提交的描述改掉用git rebase -i HEAD~3會(huì)打開一個(gè)編輯界面列出最近三條提交記錄。在這個(gè)界面里每一行開頭有一個(gè)命令pick表示保留squash表示把當(dāng)前提交合并到上一個(gè)提交reword表示只改提交信息edit表示停下來修改內(nèi)容。想合并三個(gè)提交為一條就把后兩行的pick改成squash保存后跟隨提示完善新的提交信息即可。同樣地rebase -i改寫的是歷史不要對(duì)已經(jīng)推送到遠(yuǎn)端且多人共用的提交執(zhí)行。如果只是想整理自己功能分支上的多個(gè)小提交再合并到主干那是沒問題的。中途任何一步出錯(cuò)都可以用git rebase --abort恢復(fù)到操作之前的狀態(tài)這句話值得刻在腦子里。4.3 刪除不需要的分支本地與遠(yuǎn)端的正確清理方式很多人分支用完不刪遠(yuǎn)端分支列表越來越長。我自己清理分支的習(xí)慣是功能合并進(jìn)主干確認(rèn)沒問題后就立刻把遠(yuǎn)端功能分支刪掉然后本地也刪。刪除命令如下# 刪除遠(yuǎn)端分支 git push origin --delete feature/user-login # 刪除本地分支 git branch -d feature/user-login本地刪除時(shí)-d是安全刪除Git 會(huì)檢查該分支是否已經(jīng)合并進(jìn)來如果沒合并過它會(huì)拒絕執(zhí)行這時(shí)如果想強(qiáng)制刪除用-D。但在刪除一個(gè)未合并的分支前強(qiáng)烈建議先確認(rèn)上面沒有丟失的代碼因?yàn)?D不回退。遠(yuǎn)端分支刪除后本地執(zhí)行g(shù)it fetch --prune可以把本地已經(jīng)過期的遠(yuǎn)端跟蹤分支引用也清理點(diǎn)。在 vscode 里可以看到遠(yuǎn)端分支列表變干凈。很多編輯器不自動(dòng)清理這些“遠(yuǎn)程分支殘留”所以命令行里跑一下fetch --prune很有必要。4.4 分支刪除后Git 里的“歷史包袱”怎么處理分支刪除只是刪了引用實(shí)際提交還留在倉庫的對(duì)象庫里。偶爾覺得倉庫體積越來越大想徹底清理可以執(zhí)行g(shù)it gc --prunenowgc是垃圾回收--prunenow會(huì)立即清除所有不可達(dá)對(duì)象。它對(duì)日常協(xié)作不是必需操作通常過一段時(shí)間 Git 也會(huì)自動(dòng)做類似的清理。我一般只會(huì)在刪除了一大批大文件提交、或者想給倉庫瘦身時(shí)才主動(dòng)執(zhí)行。另外如果發(fā)現(xiàn) .git 目錄大得離譜大多是有人在歷史里提交過大文件只刪分支是不夠的那就要用git filter-repo去改寫歷史了這屬于另一個(gè)話題。5. 圖形化工具實(shí)操TortoiseGit 與 IDEA/VS Code 的分支操作5.1 TortoiseGit 切換分支的菜單位置Windows 下很多人都用“小烏龜”TortoiseGit因?yàn)樗挥糜浢钣益I就完事。切換分支的入口在目錄右鍵 → TortoiseGit → Switch/Checkout彈出的窗口里選擇目標(biāo)分支即可和git switch等價(jià)。小烏龜在切換分支時(shí)也會(huì)檢查工作區(qū)是否存在未提交改動(dòng)有的話同樣會(huì)報(bào)錯(cuò)處理方式和命令行一致先 stash 或提交。它的優(yōu)勢(shì)是可視化沖突合并界面很直觀尤其適合批量處理多個(gè)文件沖突的場(chǎng)景。我印象很深的一點(diǎn)是它的日志窗口可以直接用右鍵選擇兩個(gè)提交做比較排查問題時(shí)比命令行里反復(fù) diff 效率高不少。5.2 IDEA 下復(fù)制項(xiàng)目后切換分支的坑IDEA 右下角的分支按鈕是目前我用過的 Git 圖形化操作里比較順手的一個(gè)點(diǎn)擊可以快速切換分支、創(chuàng)建新分支、推送、拉取。有一個(gè)高頻問題就是復(fù)制了一個(gè)主項(xiàng)目作為新項(xiàng)目后怎么切換分支很多人發(fā)現(xiàn)右側(cè)分支列表是空的或者切了之后代碼不變。原因通常是復(fù)制出來的項(xiàng)目沒有正確識(shí)別 Git 根目錄。解決方法是File → Settings → Version Control → Directory Mapping把復(fù)制項(xiàng)目的根目錄和 Git 倉庫對(duì)應(yīng)上或者重新通過 VCS → Enable Version Control Integration 開啟 Git 管理然后再點(diǎn)右下角分支按鈕就有分支列表了。新項(xiàng)目 clone 拉取遠(yuǎn)端倉庫時(shí)IDEA 也可以在向?qū)Ю镏苯犹?Git 倉庫 URL選好目錄就自動(dòng) clone。關(guān)鍵一點(diǎn)是 clone 下來默認(rèn)在默認(rèn)分支通常是 master/main想基于它建功能分支右下方分支列表里點(diǎn) New Branch 即可會(huì)自動(dòng)切過去。5.3 VS Code 下同項(xiàng)目多分支并行開發(fā)的安排VS Code 的 Git 操作主要集中在左側(cè)源代碼管理圖標(biāo)頂部默認(rèn)顯示當(dāng)前分支名點(diǎn)開可以切換、創(chuàng)建分支。有些前端同事習(xí)慣一個(gè)人同時(shí)維護(hù)不同分支的代碼比如一個(gè)窗口看線上穩(wěn)定版本一個(gè)窗口改新功能配合我前面提到的git worktree就能讓 VS Code 兩個(gè)窗口指向不同目錄各自獨(dú)立分支并行開發(fā)實(shí)測(cè)非常舒服。唯一的注意點(diǎn)是 .vscode 目錄不要提交進(jìn) Git建議在 .gitignore 里加上.vscode/。否則多人協(xié)作時(shí)插件配置、調(diào)試配置一沖突整個(gè)倉庫都會(huì)變得煩人。5.4 IDEA 里如何把一個(gè)分支合并到另一個(gè)分支IDEA 的分支合并邏輯也很直觀先切換到“接收方”分支也就是你希望代碼合并進(jìn)的那個(gè)分支再打開右下角分支菜單選擇“被合并方”分支點(diǎn)擊 Merge into Current 即可。這個(gè)流程和命令行是同一個(gè)道理只是把git merge feature/xxx圖形化了。不過我建議即使你習(xí)慣圖形化操作也至少記住幾個(gè)關(guān)鍵命令因?yàn)楹芏鄷r(shí)候 IDE 會(huì)莫名其妙卡住或者狀態(tài)不對(duì)打開命令行看一眼git status、git log --oneline --graph立刻能定位問題。工具只是入口Git 本身才是根本。6. 高頻報(bào)錯(cuò)與問題排查速查表6.1 “fatal: not a git repository (or any of the parent directories): .git”這個(gè)報(bào)錯(cuò)幾乎每個(gè)新手都會(huì)遇到。字面含義是當(dāng)前目錄不屬于任何 Git 倉庫。常見原因是把命令窗口開錯(cuò)目錄了或者項(xiàng)目目錄本身沒有被git init又或者項(xiàng)目是從別人那里直接復(fù)制過來的丟了 .git 目錄。排查方法三步走先pwd看當(dāng)前路徑再git rev-parse --show-toplevel看 Git 倉庫根目錄在哪如果確實(shí)沒有倉庫就回到項(xiàng)目根目錄執(zhí)行g(shù)it init。嚴(yán)格說git init只是初始化如果代碼已經(jīng)在遠(yuǎn)端倉庫更推薦git clone url而不是自己 init 再接 remote這樣可以避免很多“我不是倉庫”后續(xù)問題。6.2 Gitee 密鑰配置與 HTTPS 免密和遠(yuǎn)程倉庫協(xié)作第一關(guān)是認(rèn)證。Gitee 的 SSH 配置流程是本機(jī)生成密鑰ssh-keygen -t rsa -b 4096 -C 你的郵箱然后把~/.ssh/id_rsa.pub里的內(nèi)容復(fù)制到 Gitee 后臺(tái) SSH 公鑰設(shè)置里。配置好之后執(zhí)行ssh -T gitgitee.com如果收到成功驗(yàn)證提示就說明通了。如果使用 HTTPS 協(xié)議不想每次輸入賬號(hào)密碼Windows 上開啟憑據(jù)管理器即可git config --global credential.helper manager這樣第一次輸入后就會(huì)記在系統(tǒng)憑據(jù)里后續(xù)不用重復(fù)輸入。我自己的倉庫一般用 SSH因?yàn)槊荑€相比密碼更安全也更省事?lián)Q電腦時(shí)只需要把私鑰復(fù)制過去。6.3 分支上 commit 但未 push 的代碼怎么撤回這是個(gè)非常經(jīng)典的問題比如在 IDEA 上錯(cuò)誤地 commit 了一個(gè)半成品但還沒有 push。此時(shí)需要區(qū)分你是想保留改動(dòng)還是徹底丟棄。保留改動(dòng)并撤銷提交用軟回退git reset --soft HEAD~1這條命令會(huì)退回到提交前狀態(tài)所有改動(dòng)都留在工作區(qū)其實(shí)是暫存區(qū)想繼續(xù)改就改想重新提交就重新提交。如果想連暫存狀態(tài)也退掉、只保留工作區(qū)改動(dòng)git reset --mixed HEAD~1如果想徹底丟掉改動(dòng)用硬回退git reset --hard HEAD~1注意--hard會(huì)把工作區(qū)里那段代碼恢復(fù)成上一個(gè)提交的狀態(tài)自己寫的一大段半成品會(huì)直接消失且不可恢復(fù)。所以我個(gè)人的建議是能不 hard 就別 hard寧可先 soft 下來看一眼再?zèng)Q定哪怕是不要的代碼復(fù)制到記事本里放著也花不了幾秒鐘。6.4 換行符、中文路徑顯示與文件大小寫問題多人協(xié)作跨 Windows/macOS/Linux 時(shí)CRLF 和 LF 的換行符問題非常煩人。最常見的現(xiàn)象是明明只改了一行代碼但 diff 顯示整個(gè)文件全變。原因就是 Git 把換行符差異暴露出來了。團(tuán)隊(duì)層面建議統(tǒng)一配置# Linux/macOS 上 git config --global core.autocrlf input # Windows 上 git config --global core.autocrlf true另外 Git 默認(rèn)會(huì)把非 ASCII 的文件名轉(zhuǎn)義顯示中文目錄在命令行里亂得沒法看。執(zhí)行g(shù)it config --global core.quotepath false之后中文文件名就能正常顯示了這個(gè)熱詞里的git -c diff.mnemonicprefixfalse ...和它類似都是關(guān)掉 Git 的轉(zhuǎn)義讓輸出更直觀。還有一個(gè)隱蔽的問題Git 默認(rèn)對(duì)文件名大小寫不敏感把UserDao.java改名成userdao.java時(shí)Git 可能不識(shí)別。如果遇到這種問題用兩條命令處理git mv UserDao.java userdao.java # 或者 git config core.ignorecase false建議項(xiàng)目一開始就確定命名規(guī)范大小寫問題一旦混進(jìn)倉庫后面的清理成本非常高。我在實(shí)際工作里最深的體會(huì)是多人協(xié)作場(chǎng)景下Git 技術(shù)本身并不是越復(fù)雜越好真正決定順暢程度的是團(tuán)隊(duì)約定。分支命名統(tǒng)一、提交信息清晰、每天保持同步、合并前先看 diff、合并后及時(shí)跑測(cè)試這些看起來不起眼的習(xí)慣遠(yuǎn)遠(yuǎn)比你會(huì)不會(huì) rebase 更值錢。最后再分享一個(gè)小技巧每次大合并之前先在腦子里問自己一句“我最近一次的本地分支狀態(tài)是不是已經(jīng) push 過了”如果答案是否定的就先 push 再合并這樣就算合并現(xiàn)場(chǎng)一塌糊涂你也永遠(yuǎn)有一條安全線可以退回去。