命令行里git status、git add -p、git rebase -i用得飛起的人第一次在 PyCharm 里點(diǎn)開右下角那個(gè)分支名字時(shí)往往會(huì)愣一下這些操作在圖形界面里到底對(duì)應(yīng)哪條命令點(diǎn)下去會(huì)不會(huì)出事反過來一直用 PyCharm 圖形化版本控制、分支管理的人切回命令行又常常心里沒底覺得自己是在盲操作。這中間的落差其實(shí)不是能力問題而是沒人把界面元素和 Git 底層命令的對(duì)應(yīng)關(guān)系講清楚。這篇內(nèi)容就干這一件事把 PyCharm 的 Git 版本控制與分支管理拆成可對(duì)照、可復(fù)現(xiàn)的操作鏈路。從倉庫初始化、忽略規(guī)則、拆塊提交到分支創(chuàng)建切換、Merge 與 Rebase 的取舍、三窗格沖突解決再到歷史追溯和誤操作救火每一步我都會(huì)說明它在命令行里等價(jià)于什么、為什么這么設(shè)計(jì)、什么時(shí)候會(huì)翻車。適合兩類人看一類是剛開始用 IDE 做團(tuán)隊(duì)協(xié)作的新手另一類是命令行熟手但想搞清楚 PyCharm 到底在背后干了什么的老兵。全程基于常見實(shí)踐補(bǔ)充細(xì)節(jié)你手上的版本如果界面有差異以自己 IDE 的實(shí)際顯示為準(zhǔn)。1. 圖形化 Git 不是黑箱面板與命令的對(duì)應(yīng)關(guān)系1.1 先搞明白 PyCharm 只是 Git 的一層殼很多人對(duì) IDE 里的 Git 有天然的不信任感覺得看不見命令就不可控。實(shí)際情況恰好相反PyCharm 本身不實(shí)現(xiàn)版本控制邏輯它只是調(diào)用你系統(tǒng)上安裝的 Git 可執(zhí)行文件然后把命令輸出解析成界面。你在 Commit 面板里勾選幾個(gè)代碼塊點(diǎn)提交它在背后執(zhí)行的就是一條帶路徑參數(shù)的git commit你在分支彈窗里點(diǎn) Rebase它執(zhí)行的就是git rebase。理解了這一層界面上任何一個(gè)按鈕你都能反推出它的命令風(fēng)險(xiǎn)也就變得可評(píng)估了。驗(yàn)證方法很簡(jiǎn)單打開 Git 工具窗口里的 Console 標(biāo)簽頁你在圖形界面做的每一次操作都能在這里看到對(duì)應(yīng)的命令和輸出。我習(xí)慣在處理復(fù)雜合并之前先把這個(gè) Console 面板開著操作完回頭掃一眼執(zhí)行了什么。這個(gè)習(xí)慣救過我兩次一次是發(fā)現(xiàn)某個(gè)撤銷按鈕實(shí)際執(zhí)行的是硬回退一次是發(fā)現(xiàn)提交時(shí) IDE 自動(dòng)加了簽名參數(shù)導(dǎo)致鉤子行為不同。配置入口在 Settings 里的 Version Control 分組第一項(xiàng) Git 會(huì)顯示當(dāng)前檢測(cè)到的可執(zhí)行文件路徑和版本號(hào)。如果這里顯示Git not found說明系統(tǒng) PATH 沒配好手動(dòng)指定安裝目錄下的可執(zhí)行文件即可。版本上有一點(diǎn)值得注意Git 2.23 之后git checkout被拆成了git switch和git restore較新的 IDE 版本在切換分支時(shí)調(diào)用的已經(jīng)是git switch如果你機(jī)器上的 Git 版本太老某些操作會(huì)靜默失敗或者報(bào)錯(cuò)信息很奇怪。團(tuán)隊(duì)統(tǒng)一環(huán)境的時(shí)候把 Git 版本也納入約定范圍能省掉很多莫名其妙的排查。1.2 三個(gè)入口各管什么別混著用PyCharm 里跟 Git 相關(guān)的界面主要分布在三個(gè)地方職責(zé)其實(shí)分得很清楚混用會(huì)讓人抓狂。入口主要職責(zé)典型操作提交工具窗口Commit管理待提交的改動(dòng)勾選代碼塊、寫提交信息、提交并推送Git 工具窗口Log查看與操作提交歷史查看分支圖、Cherry-Pick、Revert、Reset右下角分支菜單分支級(jí)操作新建、切換、合并、變基、拉取底部狀態(tài)欄還有幾個(gè)容易被忽略的信息當(dāng)前分支名、是否有未推送提交向上的箭頭數(shù)字、是否有未拉取提交向下的箭頭數(shù)字。我見過不少人只看提交按鈕不看狀態(tài)欄結(jié)果在落后遠(yuǎn)端十幾個(gè)提交的分支上繼續(xù)寫代碼最后合并時(shí)沖突爆炸。養(yǎng)成一個(gè)習(xí)慣動(dòng)手寫代碼前掃一眼狀態(tài)欄的箭頭向下的數(shù)字不為零就先更新。編輯器里的文件名顏色也是信息源。默認(rèn)配色下未納入版本控制的文件是紅色新加且已暫存的是綠色修改過的是藍(lán)色被忽略的是灰褐色。這套顏色可以在 Settings 的 Version Control 下的 File Status Colors 里改團(tuán)隊(duì)里如果有人用深色主題有人用淺色主題統(tǒng)一一下配色方案能減少溝通成本。至于每個(gè)文件具體改了哪幾行看行號(hào)右側(cè)的變更標(biāo)記條就夠了綠色豎條是新增行藍(lán)色是修改行灰色小三角是刪除位置點(diǎn)一下能看到該行的原始內(nèi)容。1.3 為什么建議先在 IDE 里熟悉再回命令行有個(gè)觀點(diǎn)我想說清楚圖形化版本控制不是新手拐杖它是降低認(rèn)知負(fù)荷的工具。分支合并這類操作沖突文件可能幾十個(gè)在命令行里你要反復(fù)git status看還剩哪些沒解決在 IDE 里左側(cè)列著所有沖突文件解決一個(gè)劃掉一個(gè)進(jìn)度一目了然。再比如拆塊提交命令行的git add -p要一個(gè)個(gè) chunk 交互式回答 y/nPyCharm 里直接勾復(fù)選框視覺上還帶著 diff 高亮。但反過來說完全依賴界面也有代價(jià)。有幾種情況命令行明顯更順手批量操作比如給二十個(gè)文件同時(shí)打補(bǔ)丁、復(fù)雜的交互式變基、需要精確控制提交時(shí)間的場(chǎng)景、以及排查為什么 IDE 顯示的狀態(tài)和實(shí)際不一致這類疑難雜癥。我的建議是把界面當(dāng)主力把命令行 Console 當(dāng)兜底遇到界面做不到的事直接在 IDE 內(nèi)置終端里敲命令兩邊共用同一個(gè)工作區(qū)互不沖突。2. 從零接入倉庫初始化、忽略規(guī)則與第一次提交2.1 兩種接入路徑新建倉庫還是克隆已有倉庫新項(xiàng)目的起步方式取決于代碼在哪。如果是本地已經(jīng)有一堆文件、想納入版本控制走 VCS 菜單里的Enable Version Control Integration選擇 Git它會(huì)在項(xiàng)目根目錄執(zhí)行g(shù)it init。注意這一步只是創(chuàng)建了.git目錄還沒有任何提交此時(shí)所有文件都是未跟蹤狀態(tài)。如果代碼已經(jīng)在遠(yuǎn)端倉庫里走Get from VCS填倉庫地址選擇本地目錄它會(huì)執(zhí)行g(shù)it clone并自動(dòng)把項(xiàng)目配置好這是團(tuán)隊(duì)協(xié)作里最常見的路徑。一個(gè)容易踩的細(xì)節(jié)初始化倉庫的位置。如果你只有某個(gè)子目錄需要版本控制而項(xiàng)目根目錄是另一個(gè)更大的目錄一定要在正確的層級(jí)執(zhí)行初始化。我見過有人在用戶主目錄下誤執(zhí)行了初始化結(jié)果一個(gè)git add .把整個(gè)家目錄的東西都想加進(jìn)去.git目錄膨脹到幾個(gè) G。所以初始化之后第一件事永遠(yuǎn)是確認(rèn)根目錄對(duì)不對(duì)看一眼 IDE 里顯示的項(xiàng)目根和.git目錄是否在同一層。克隆路徑上還有個(gè)憑證問題。用 HTTPS 地址克隆時(shí)第一次推送會(huì)讓你輸入賬號(hào)密碼或者令牌用 SSH 地址則需要提前配好密鑰對(duì)把公鑰上傳到遠(yuǎn)端。IDE 在 Settings 的 Version Control 下的 Git 配置里可以指定 SSH 可執(zhí)行文件Windows 上尤其要注意這一點(diǎn)系統(tǒng)自帶的和 Git 安裝包里帶的那份可能不是同一個(gè)選錯(cuò)了會(huì)出現(xiàn)命令行能推、IDE 推不了的怪現(xiàn)象。2.2 忽略規(guī)則要在第一次提交前寫好.gitignore這個(gè)東西最理想的創(chuàng)建時(shí)機(jī)是第一次提交之前。事后再補(bǔ)不是不行但已經(jīng)進(jìn)了歷史的文件不會(huì)因?yàn)榧恿撕雎砸?guī)則就消失你還得額外執(zhí)行一次從索引里移除的操作多繞一圈。PyCharm 新建.gitignore文件時(shí)可以選模板Python 項(xiàng)目選 Python 模板會(huì)帶上一堆常見產(chǎn)物目錄另外還有專門針對(duì) IDE 配置目錄的模板可以疊加使用。關(guān)于.idea目錄到底要不要提交這是團(tuán)隊(duì)協(xié)作里爭(zhēng)論最多的話題之一我的實(shí)踐結(jié)論是拆開看不要一刀切。整個(gè)目錄要么全提交要么全忽略這兩種極端做法都有問題。路徑是否提交理由.idea/workspace.xml不提交記錄個(gè)人窗口布局、打開的文件、運(yùn)行狀態(tài)每人不同.idea/shelf/不提交本地?cái)R置的改動(dòng)純個(gè)人數(shù)據(jù).idea/codeStyles/建議提交統(tǒng)一代碼風(fēng)格避免格式化產(chǎn)生大量無意義 diff.idea/inspectionProfiles/建議提交統(tǒng)一靜態(tài)檢查規(guī)則.idea/dictionaries/建議提交團(tuán)隊(duì)共享拼寫詞典.idea/vcs.xml建議提交版本控制映射關(guān)系.idea/*.iml視情況模塊配置文件Maven/Gradle 項(xiàng)目通常由構(gòu)建工具生成可忽略實(shí)際操作上可以在.gitignore里先寫.idea/*全忽略再用取反規(guī)則把需要共享的子目錄放出來類似.idea/codeStyles前面加感嘆號(hào)。這套寫法新手容易寫錯(cuò)順序記住一條取反規(guī)則必須寫在忽略規(guī)則之后且父目錄被忽略時(shí)子目錄的取反往往失效穩(wěn)妥做法是把父目錄寫成.idea/*帶星號(hào)而不是.idea/不帶星號(hào)。臨時(shí)想忽略某個(gè)已跟蹤文件的改動(dòng)別去改.gitignore用git update-index --skip-worktree這類索引級(jí)手段或者干脆用 IDE 的 Shelve 把改動(dòng)收起來。改忽略規(guī)則影響的是所有人索引標(biāo)記只影響你自己。2.3 第一次提交前必須過的三個(gè)檢查第一次提交的坑最集中因?yàn)檫@時(shí)候項(xiàng)目結(jié)構(gòu)和團(tuán)隊(duì)約定都還沒定型。我在帶人的時(shí)候會(huì)強(qiáng)制要求走完這三步。第一步看一眼完整的變更列表。打開提交工具窗口確認(rèn)列出來的文件都是你想提交的。這里最容易出錯(cuò)的是那些自動(dòng)生成的東西虛擬環(huán)境目錄、編譯產(chǎn)物、本地配置文件、日志文件、數(shù)據(jù)庫文件。有一次一個(gè)同事把本地調(diào)試用的 SQLite 數(shù)據(jù)庫文件提交上去了后面每次跑測(cè)試都會(huì)產(chǎn)生變更天天在變更列表里礙眼追了兩周才徹底清理干凈。第二步檢查換行符。這是跨平臺(tái)協(xié)作的第一大坑Windows 上默認(rèn)換行是 CRLFLinux 和 macOS 上是 LF。如果團(tuán)隊(duì)里有人用 Windows 有人用 Mac不加約束的話一個(gè)文件可能因?yàn)閾Q行符不同被整篇標(biāo)記為修改diff 根本沒法看。解決方式有兩條路一是在 Git 配置里設(shè)core.autocrlfWindows 設(shè)true提交時(shí)轉(zhuǎn) LF檢出時(shí)轉(zhuǎn) CRLFmacOS 和 Linux 設(shè)input提交時(shí)轉(zhuǎn) LF檢出時(shí)不變二是更推薦的做法在倉庫根目錄加一個(gè).gitattributes文件顯式聲明各類文件的換行符策略讓規(guī)則跟著倉庫走而不是跟著每個(gè)人的機(jī)器走。PyCharm 的設(shè)置里也有單獨(dú)的換行符選項(xiàng)位置在編輯器代碼風(fēng)格那一欄但它影響的是新建文件歷史文件的換行符還是得靠 Git 層配置來統(tǒng)一。第三步確認(rèn)提交身份。提交信息里的作者名和郵箱來自 Git 全局配置如果這臺(tái)機(jī)器是共用的或者你之前配過別的身份提交記錄上就會(huì)掛錯(cuò)名字。在 IDE 的終端里執(zhí)行g(shù)it config user.name和git config user.email確認(rèn)一下需要改就在倉庫級(jí)別重新設(shè)一遍倉庫級(jí)配置優(yōu)先級(jí)高于全局。3. 提交面板的精細(xì)化操作拆塊提交、改歷史與提交前檢查3.1 部分提交把一次改動(dòng)拆成幾個(gè)干凈的提交有條經(jīng)驗(yàn)值得反復(fù)強(qiáng)調(diào)提交的粒度決定了他日排查問題的成本。一次提交里塞進(jìn)三個(gè)不相關(guān)的改動(dòng)將來要回退其中一個(gè)你就得手工拆。PyCharm 的提交面板在這一點(diǎn)上給的能力比命令行直觀得多。在提交工具窗口里每個(gè)文件左邊有復(fù)選框展開文件后能看到具體的變更塊chunk每個(gè)塊左邊也有復(fù)選框甚至單行都能勾。你勾選哪些提交時(shí)就只包含哪些剩下的留在工作區(qū)。這個(gè)操作背后等價(jià)于git add -p加git commit但省掉了交互式回答的繁瑣。具體流程我一般這么走先寫代碼寫完打開提交面板從上往下過一遍把屬于同一個(gè)邏輯變更的塊勾上寫一條對(duì)應(yīng)的提交信息提交。然后剩下的塊繼續(xù)分組。舉個(gè)常見的場(chǎng)景你在實(shí)現(xiàn)一個(gè)新功能的過程中順手修了一個(gè)拼寫錯(cuò)誤、又調(diào)整了一處配置。這應(yīng)該是三個(gè)提交而不是一個(gè)。功能性改動(dòng)、修正性改動(dòng)、配置類改動(dòng)混在一起提交將來做二分查找定位問題時(shí)那個(gè)大提交就是個(gè)黑盒。有個(gè)細(xì)節(jié)要注意同一行既有功能改動(dòng)又有格式調(diào)整時(shí)行級(jí)勾選做不到拆分只能拆到塊級(jí)。這種時(shí)候我的做法是先格式化再寫功能或者反過來分開兩次提交別硬拆。3.2 提交信息、檢查項(xiàng)與提交并推送提交信息輸入框上方的幾個(gè)復(fù)選框價(jià)值比很多人以為的大。默認(rèn)可能有優(yōu)化導(dǎo)入重排代碼運(yùn)行代碼分析之類的選項(xiàng)勾上之后提交前會(huì)自動(dòng)跑一遍對(duì)應(yīng)動(dòng)作有問題會(huì)在提交對(duì)話框里提示。團(tuán)隊(duì)里如果有統(tǒng)一的代碼規(guī)范把重排代碼和優(yōu)化導(dǎo)入勾上能避免格式化產(chǎn)生的 diff混進(jìn)功能提交里。提交信息本身也值得規(guī)范一下。最基礎(chǔ)的要求是首行簡(jiǎn)明扼要、不超過五六十個(gè)字符需要詳細(xì)說明的話空一行再寫正文。更進(jìn)一步的可以在 Settings 的 Version Control 下的 Commit 配置里開啟提交信息檢查用正則約束格式比如要求以特定前綴開頭。這個(gè)功能對(duì)小團(tuán)隊(duì)特別有用因?yàn)樗谀泓c(diǎn)提交的那一刻就攔住不合規(guī)的信息比事后讓人改歷史容易一萬倍。右下角的提交并推送是個(gè)雙刃劍。它省了一步操作但也讓提交和推送這兩個(gè)語義不同的動(dòng)作耦合在一起。我個(gè)人的習(xí)慣是本地提交隨便做改錯(cuò)了還能撤推送一定要單獨(dú)確認(rèn)因?yàn)橥粕先サ臇|西可能已經(jīng)被別人拉走了。團(tuán)隊(duì)如果開了保護(hù)分支推送到受保護(hù)分支會(huì)直接被拒這時(shí)候還得回頭處理不如一開始就分兩步走。3.3 提交寫錯(cuò)了怎么改Amend、Undo Commit 與交互式變基三種情況三種處理方式。剛提交完發(fā)現(xiàn)漏了一個(gè)文件或者提交信息寫錯(cuò)了這時(shí)候用 Amend。在提交面板勾上要補(bǔ)的文件然后從提交按鈕的下拉菜單里選修改提交它會(huì)把新內(nèi)容并入上一次提交同時(shí)允許你改提交信息。背后執(zhí)行的是git commit --amend。有個(gè)前提必須確認(rèn)上一次提交還沒推送到遠(yuǎn)端。如果已經(jīng)推了改完之后本地和遠(yuǎn)端歷史就不一致再推就得強(qiáng)制覆蓋風(fēng)險(xiǎn)很大。提交本身想整個(gè)撤銷退回工作區(qū)用 Undo Commit?？旖萱I是 CtrlAltZWindows/Linux效果等價(jià)于git reset --soft HEAD~1提交沒了改動(dòng)原樣留在工作區(qū)文件狀態(tài)回到已暫存。這個(gè)操作我?guī)缀趺刻於荚谟糜绕涫窃谔峤恢罅⒖贪l(fā)現(xiàn)這不該單獨(dú)成一個(gè)提交的時(shí)候。如果是連續(xù)好幾個(gè)提交都寫亂了想合并、重排、改信息那就得用交互式變基。在 Git 工具窗口的 Log 面板里選中某個(gè)提交右鍵選從這里開始交互式變基彈出的表格里每一行是一個(gè)提交可以拖拽排序、標(biāo)記為 squash合并到上一個(gè)、reword改信息、drop丟棄。這是 PyCharm 里少數(shù)幾個(gè)比命令行更直觀的操作因?yàn)槊钚欣飏ebase -i打開的是一個(gè)文本編輯器順序和操作的對(duì)應(yīng)關(guān)系全靠想象。提示交互式變基會(huì)重寫提交哈希只對(duì)本地未推送的提交使用。已經(jīng)推送到公共分支的提交用 Revert 生成反向提交不要?jiǎng)託v史。4. 分支的創(chuàng)建、切換與合并右下角彈窗能做的和不能做的4.1 分支操作的完整清單與執(zhí)行時(shí)機(jī)右下角的分支名點(diǎn)開是一個(gè)覆蓋了絕大多數(shù)分支操作的面板。新建分支時(shí)它會(huì)問你要從哪個(gè)提交起頭默認(rèn)是當(dāng)前 HEAD也可以手動(dòng)指定某個(gè)歷史提交。這里有個(gè)實(shí)用選項(xiàng)勾選檢出表示創(chuàng)建后立即切過去不勾就只是創(chuàng)建。我傾向于勾上因?yàn)閯?chuàng)建分支的目的通常就是要馬上在上面干活。切換分支時(shí)最大的風(fēng)險(xiǎn)是工作區(qū)有未提交的改動(dòng)。Git 會(huì)嘗試把這些改動(dòng)帶過去如果目標(biāo)分支上相同文件有沖突切換就會(huì)失敗。PyCharm 在這種情況下會(huì)彈提示給你幾個(gè)選擇擱置改動(dòng)Shelve、強(qiáng)制切換Smart Checkout、或者取消。Smart Checkout 的背后邏輯是把本地改動(dòng)先 stash 起來切完再 pop 回去多數(shù)情況下能成功但如果 pop 時(shí)沖突你還得再解決一次。我的做法是切換分支前要么提交要么擱置別指望自動(dòng)搬運(yùn)。重命名和刪除這兩個(gè)操作看著簡(jiǎn)單其實(shí)有講究。重命名只改本地分支名遠(yuǎn)端的舊名字還在需要單獨(dú)推一次刪除再推一次新分支或者在推送時(shí)留意提示。刪除分支時(shí)未合并的分支會(huì)被拒絕刪除IDE 會(huì)提示你該分支還有未合并的提交這時(shí)候要用強(qiáng)制刪除。如果手滑刪了一個(gè)還有用的分支別慌用 Reflog 能找回來這一點(diǎn)在第 6 節(jié)詳細(xì)說。4.2 Merge 還是 Rebase在 IDE 里怎么選、怎么執(zhí)行這個(gè)選擇題的答案取決于分支性質(zhì)不是個(gè)人偏好。我按場(chǎng)景給結(jié)論場(chǎng)景推薦方式原因功能分支同步主分支的最新代碼Rebase保持功能分支提交線干凈不產(chǎn)生一堆合并主分支的噪音提交功能分支合入主分支Merge或壓縮合并保留功能開發(fā)的完整上下文出問題好回退整個(gè)功能多人協(xié)作的公共分支Merge不改寫歷史不影響別人本地臨時(shí)分支整理Rebase把零碎提交壓成有意義的幾個(gè)執(zhí)行 Merge 的入口在分支面板里先切到目標(biāo)分支然后在面板里選中要合進(jìn)來的分支選合并到當(dāng)前分支。如果遇到?jīng)_突IDE 會(huì)彈出沖突解決界面處理完再提交。執(zhí)行 Rebase 的入口在同一個(gè)面板里選中要變基到的分支選將當(dāng)前分支變基到。變基過程中如果每個(gè)提交都有沖突會(huì)一段段停下來讓你處理處理完點(diǎn)繼續(xù)。這個(gè)過程比合并累人所以我一般建議在功能分支上頻繁地做小規(guī)模變基別等積累了三十個(gè)提交再一次性變基那時(shí)候沖突會(huì)一層套一層非常難受。還有個(gè)常被忽略的配置更新項(xiàng)目時(shí)默認(rèn)用合并還是變基。這個(gè)可以在 Settings 的 Version Control 下的 Git 配置里設(shè)對(duì)應(yīng)到快捷鍵 CtrlT 的更新動(dòng)作。團(tuán)隊(duì)里如果約定功能分支用變基、主分支用合并把這個(gè)默認(rèn)值配好能省掉每次手動(dòng)選擇的麻煩。配錯(cuò)的表現(xiàn)是你明明想變基點(diǎn)了更新卻發(fā)現(xiàn)多出一個(gè)合并提交。4.3 分支面板做不到的事不是所有分支操作都有界面入口。比如刪除遠(yuǎn)端分支面板里雖然有入口但操作完遠(yuǎn)端引用不會(huì)立刻刷新需要手動(dòng)執(zhí)行一次拉取或者清理才能看到變化。再比如給分支設(shè)置上游追蹤面板里能做但藏得比較深我通常直接在終端敲git branch --set-upstream-to。另一個(gè)盲區(qū)是多個(gè)工作區(qū)并行。Git 支持git worktree可以同時(shí)檢出多個(gè)分支到不同目錄這在需要一邊跑測(cè)試一邊改代碼時(shí)特別有用。PyCharm 對(duì) worktree 的支持是通過打開不同目錄實(shí)現(xiàn)的不算真正的集成但能用。5. 沖突現(xiàn)場(chǎng)三窗格合并工具的逐行處理與驗(yàn)證5.1 沖突到底在沖突什么先把原理說透后面操作才有依據(jù)。合并兩個(gè)分支時(shí)Git 會(huì)找到它們的共同祖先提交然后比較祖先到當(dāng)前分支改了什么和祖先到目標(biāo)分支改了什么。如果兩邊改的是同一塊區(qū)域的同一批行或者一邊改了一邊刪了Git 就不知道該聽誰的把這塊標(biāo)成沖突兩邊的內(nèi)容都塞進(jìn)文件里用一串尖括號(hào)和等號(hào)分隔開等人工裁決。明白了這個(gè)模型你就知道沖突不是文件不同而是同一位置的改動(dòng)無法自動(dòng)調(diào)和。兩個(gè)分支都改了同一個(gè)文件的不同位置Git 是能自動(dòng)合并的壓根不會(huì)找你。所以沖突文件數(shù)量多往往說明兩個(gè)分支分叉的時(shí)間太長改動(dòng)面重疊嚴(yán)重。減少?zèng)_突的根本辦法是短分支、勤同步而不是沖突出現(xiàn)后處理得多快。沖突標(biāo)記的樣子是一排左尖括號(hào)標(biāo)記當(dāng)前分支版本一排等號(hào)分隔一排右尖括號(hào)標(biāo)記合進(jìn)來的版本。這三段在 PyCharm 里被渲染成可視化界面不用直接看這些符號(hào)。5.2 三窗格編輯器怎么讀、怎么點(diǎn)雙擊沖突文件或者從沖突文件列表里點(diǎn)進(jìn)去會(huì)打開合并編輯器。界面布局是三塊左邊是本地版本右邊是外部版本中間是合并結(jié)果底部還有一個(gè)共同祖先版本。四個(gè)區(qū)域各有用處缺一不可。底部的祖先版本經(jīng)常被忽略但它才是判斷該保留誰的依據(jù)。比如左右兩邊都改了一行你需要知道原來是什么樣才能判斷哪邊的改動(dòng)是修正、哪邊的改動(dòng)是覆蓋。沒有祖先視圖你只能靠猜。中間的結(jié)果面板上方有三個(gè)按鈕分別對(duì)應(yīng)接受左側(cè)接受右側(cè)接受合并結(jié)果。這里的措辭不同版本略有差異語義是全采用本地、全采用外部、采用你手工編輯后的內(nèi)容。對(duì)于明顯的場(chǎng)景直接點(diǎn)前兩個(gè)就夠了對(duì)于兩邊改動(dòng)都要保留的情況就得在中間手動(dòng)編輯把兩段內(nèi)容拼成想要的樣子。自動(dòng)解決按鈕也值得一用它會(huì)對(duì)所有沒有實(shí)質(zhì)沖突的變更塊批量應(yīng)用合并只留下真正需要判斷的塊。幾十個(gè)沖突文件的時(shí)候先用自動(dòng)解決清掉簡(jiǎn)單的剩下的手工處理效率能差一倍。有些沖突涉及整段方法的刪除和新增嵌套層級(jí)很深肉眼看容易暈。這時(shí)候把編輯器的折疊和差異高亮都用上折疊掉不相關(guān)的代碼塊只留沖突區(qū)域展開視野會(huì)清爽很多。5.3 解決完之后的三道驗(yàn)證沖突處理完不等于事情結(jié)束實(shí)際翻車往往發(fā)生在以為處理完了之后。第一道驗(yàn)證是標(biāo)記已解決。在合并編輯器里點(diǎn)應(yīng)用之后文件會(huì)從沖突列表里消失進(jìn)入待提交狀態(tài)。如果你直接在編輯器里手動(dòng)刪了沖突標(biāo)記、保存關(guān)掉但沒有走標(biāo)記為已解決這一步Git 仍然認(rèn)為這個(gè)文件處于沖突狀態(tài)后續(xù)提交會(huì)報(bào)錯(cuò)提示還有未合并的路徑。這個(gè)坑非常常見尤其是在編輯器里順手改的時(shí)候。第二道驗(yàn)證是全文搜索沖突標(biāo)記。沖突塊處理不干凈、殘留半截標(biāo)記的情況時(shí)有發(fā)生尤其是文件很大的時(shí)候。用全局搜索搜左尖括號(hào)連續(xù)七個(gè)字符正常應(yīng)該零結(jié)果。這一步我每次解決完沖突都會(huì)做比事后測(cè)試報(bào)語法錯(cuò)誤再回頭找快得多。第三道驗(yàn)證是跑一遍構(gòu)建或測(cè)試。有些沖突表現(xiàn)為代碼能編譯但邏輯錯(cuò)了比如兩邊各加了一個(gè)初始化調(diào)用合并后變成調(diào)用兩次。這種問題只有跑起來才能發(fā)現(xiàn)。合并完成后先本地跑一遍測(cè)試再提交這個(gè)順序別顛倒。真要是合并提交推上去之后才發(fā)現(xiàn)問題回退一個(gè)合并提交比回退普通提交麻煩得多。注意合并沖突期間不要執(zhí)行拉取操作。Git 在合并未完成的狀態(tài)下拒絕新的合并提示信息通常很含糊容易讓人誤以為是網(wǎng)絡(luò)問題。6. 追溯與救火Log、Annotate、回退與誤操作兜底6.1 Log 面板不只是看提交記錄Git 工具窗口的 Log 標(biāo)簽頁很多人只用來掃一眼提交列表其實(shí)它是信息密度最高的面板。頂部的過濾框支持按作者、日期、提交信息、路徑組合過濾語法跟命令行參數(shù)類似。想查某個(gè)文件在最近三個(gè)月內(nèi)被誰改過把文件從項(xiàng)目視圖拖進(jìn)去或者直接輸入路徑前綴就行。分支圖那一欄值得展開說。勾選顯示所有分支之后你會(huì)看到彩色的線條交纏在一起每個(gè)圓點(diǎn)是一個(gè)提交線條分叉表示分支創(chuàng)建線條匯合表示合并?？炊嗔四芤谎壅J(rèn)出這個(gè)分支是從三個(gè)月前的老提交拉出來的一直沒同步過主分支這類分支合并起來必然痛苦提前預(yù)警。右鍵菜單里的操作才是重點(diǎn)Cherry-Pick 把某個(gè)提交摘到當(dāng)前分支Revert Commit 生成一個(gè)反向提交抵消某次改動(dòng)Reset Current Branch to Here 把當(dāng)前分支指針移到選中的提交還有前面提過的交互式變基。這些操作的入口都在右鍵里用熟了比在命令行拼參數(shù)快。6.2 Annotate定位某行代碼是誰在什么時(shí)候改的編輯器左邊行號(hào)區(qū)域右鍵選使用 Git 追溯注釋有的版本叫 Annotate每一行左邊會(huì)顯示最后一次修改它的提交信息和作者。把鼠標(biāo)懸停在某個(gè)注釋上能看到完整的提交信息、時(shí)間、以及那次提交對(duì)這個(gè)文件的所有改動(dòng)。這個(gè)功能在排查問題時(shí)的價(jià)值極高。舉個(gè)例子某段邏輯突然開始報(bào)錯(cuò)你懷疑是參數(shù)變了用 Annotate 一查發(fā)現(xiàn)這行是上周某個(gè)提交改的點(diǎn)進(jìn)去看那次提交的完整 diff發(fā)現(xiàn)連帶改了別的地方問題一目了然。整個(gè)過程五分鐘比滿倉庫翻代碼快太多。進(jìn)階用法是追溯上一次修改。如果發(fā)現(xiàn)某行的改動(dòng)是在做格式化沒有實(shí)質(zhì)變化可以繼續(xù)往前追溯一直追到真正改了邏輯的那次提交。多次追溯能畫出這個(gè)文件的修改脈絡(luò)對(duì)于理解一段歷史悠久的祖?zhèn)鞔a特別有用。再看一眼狀態(tài)欄和編輯器提示Annotate 視圖是可以關(guān)掉的右鍵選隱藏注釋就回到正常編輯。有些人不小心打開之后不知道怎么關(guān)一直帶著一堆灰色小字寫代碼體驗(yàn)很差。6.3 三種回退方式的區(qū)別與選用這是最容易出事的地方因?yàn)槿齻€(gè)操作的界面看起來差不多后果差別巨大。操作命令等價(jià)對(duì)工作區(qū)的影響對(duì)歷史的影響適用場(chǎng)景撤銷提交Undo Commitgit reset --soft HEAD~1改動(dòng)完整保留抹掉最后一次提交剛提交完發(fā)現(xiàn)問題未推送回退提交Revert Commitgit revert hash自動(dòng)生成反向改動(dòng)新增一個(gè)抵消提交已推送到公共分支或需要留痕重置到此處Resetgit reset --mode hash取決于模式移動(dòng)分支指針本地整理歷史未推送Reset 又分三種模式IDE 在彈窗里會(huì)讓你選軟重置只移指針改動(dòng)留在工作區(qū)混合重置移指針并清空暫存區(qū)改動(dòng)留在工作區(qū)硬重置移指針并丟棄所有改動(dòng)工作區(qū)回到目標(biāo)提交的狀態(tài)。硬重置是唯一一個(gè)會(huì)真正刪掉你代碼的操作做之前務(wù)必確認(rèn)目標(biāo)提交選對(duì)了且當(dāng)前改動(dòng)沒有價(jià)值。什么時(shí)候用哪個(gè)我給個(gè)簡(jiǎn)單判斷只要這個(gè)提交別人可能已經(jīng)拉走了就只能用 Revert絕不能用 Reset。判斷依據(jù)很簡(jiǎn)單看分支是不是公共分支看提交有沒有推送。拿不準(zhǔn)的時(shí)候先建一個(gè)臨時(shí)分支指向當(dāng)前位置再操作出問題還能切回去。6.4 手滑之后的兩層兜底第一層兜底是 Reflog。Git 會(huì)記錄每一次 HEAD 的移動(dòng)即使你硬重置到一個(gè)老提交、或者刪掉了一個(gè)分支那些提交對(duì)象在一段時(shí)間內(nèi)仍然存在只是沒有分支指向它們。在 Git 工具窗口的 Log 面板里分支下拉菜單里可以找到查看 Reflog 的入口也可以在終端執(zhí)行g(shù)it reflog。找到誤操作之前的那條記錄右鍵重置到那個(gè)位置或者新建一個(gè)分支指向它代碼就回來了。第二層兜底是 IDE 的本地歷史。這個(gè)功能跟 Git 完全無關(guān)是編輯器自己定期給文件拍快照記錄在項(xiàng)目配置目錄里。哪怕文件從來沒提交過、哪怕 Git 倉庫被整個(gè)刪了本地歷史依然能找回某天某個(gè)時(shí)刻的文件內(nèi)容。入口在編輯器或項(xiàng)目視圖的右鍵菜單里選本地歷史下的顯示歷史。我遇到過最離譜的一次事故是有人把整個(gè)源碼目錄清空了Git 那邊也沒提交過最后靠本地歷史恢復(fù)的。這個(gè)功能建議所有人都知道它在哪并且別把項(xiàng)目配置目錄加進(jìn)忽略規(guī)則之外的清理腳本里。最后說個(gè)小技巧。團(tuán)隊(duì)協(xié)作里提交信息和分支命名其實(shí)是低成本的溝通工具。分支名寫成fix/訂單列表分頁錯(cuò)亂和寫成dev2三個(gè)月后你自己都想不起來 dev2 是干什么的。我現(xiàn)在的習(xí)慣是分支名帶上類型前綴和一句短語提交信息首行寫清楚做了什么正文寫為什么這么做。這套習(xí)慣堅(jiān)持下來回頭看 Log 面板的時(shí)候它就不只是一堆哈希而是一份能讀的變更說明書。我在實(shí)際使用中最大的體會(huì)是PyCharm 的版本控制功能真正的價(jià)值不在于省掉幾個(gè)命令而在于把狀態(tài)可視化了。哪些文件改了、哪些提交沒推、哪些沖突沒解、當(dāng)前在哪個(gè)分支這些信息在命令行里需要反復(fù)敲命令確認(rèn)在界面里一眼就能看到。把這份可見性用好比記住多少個(gè)快捷鍵重要得多。