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