1. 項(xiàng)目概述為什么你需要理解Git的“內(nèi)臟”干了這么多年開(kāi)發(fā)我見(jiàn)過(guò)太多人把Git用成了“黑箱魔法”。每天敲著git pull、git merge、git push代碼沖突了就手足無(wú)措回退版本像在玩掃雷一不小心就把團(tuán)隊(duì)倉(cāng)庫(kù)搞炸。問(wèn)題的根源往往不在于命令記不住而在于對(duì)Git底層到底在干什么一片模糊。你以為的“合并分支”在Git眼里可能完全是另一幅景象你以為簡(jiǎn)單的“推拉”背后是遠(yuǎn)程與本地多個(gè)倉(cāng)庫(kù)對(duì)象復(fù)雜的握手與協(xié)商。這篇內(nèi)容就是要把Git的“引擎蓋”掀開(kāi)讓你看清楚里面每一個(gè)齒輪是如何咬合的。我們不滿足于只會(huì)用幾個(gè)命令而是要深挖其設(shè)計(jì)哲學(xué)和核心數(shù)據(jù)結(jié)構(gòu)。當(dāng)你理解了.git目錄里那些看似神秘的文件objects、refs、HEAD理解了每一次提交commit本質(zhì)上是什么理解了分支branch和標(biāo)簽tag的真實(shí)身份你會(huì)發(fā)現(xiàn)所有那些令人頭疼的合并沖突、版本回退、歷史改寫(xiě)問(wèn)題都有了清晰的解決路徑。這不是一篇命令手冊(cè)而是一次從“用戶”到“理解者”的認(rèn)知升級(jí)?？赐曛竽悴粫?huì)再對(duì)Git感到恐懼反而會(huì)欣賞其設(shè)計(jì)的精妙并真正掌控你的代碼版本。2. Git核心對(duì)象模型一切皆對(duì)象一切皆哈希要理解合并與推拉必須先理解Git存儲(chǔ)數(shù)據(jù)的基石——對(duì)象模型。這是Git區(qū)別于其他版本控制系統(tǒng)如SVN最核心的設(shè)計(jì)。2.1 四種核心對(duì)象類(lèi)型及其關(guān)系Git倉(cāng)庫(kù)本質(zhì)上是一個(gè)鍵值對(duì)數(shù)據(jù)庫(kù)。鍵Key是一個(gè)40位的SHA-1哈希值現(xiàn)在Git已支持SHA-256值Value是經(jīng)過(guò)壓縮的數(shù)據(jù)內(nèi)容。這個(gè)哈希值由數(shù)據(jù)內(nèi)容本身計(jì)算得出這意味著內(nèi)容定哈希定。Git主要管理四種對(duì)象Blob對(duì)象這是最基礎(chǔ)的對(duì)象存儲(chǔ)文件的內(nèi)容。注意它只存內(nèi)容不存文件名。一個(gè)100KB的文件和一個(gè)1KB的文件在Git眼里都是一個(gè)個(gè)Blob。當(dāng)你修改文件并git add時(shí)Git就是為文件內(nèi)容創(chuàng)建了新的Blob對(duì)象。Tree對(duì)象這相當(dāng)于一個(gè)目錄的快照。它存儲(chǔ)了一組條目每條目包含文件模式如100644代表普通文件、對(duì)象類(lèi)型blob或tree、對(duì)象的SHA-1哈希值、以及文件名或目錄名。一個(gè)Tree對(duì)象引用著當(dāng)前目錄下所有文件和子目錄對(duì)應(yīng)的Blob或Tree對(duì)象。git commit時(shí)會(huì)為項(xiàng)目的根目錄創(chuàng)建一個(gè)頂層的Tree對(duì)象。Commit對(duì)象這是版本歷史的節(jié)點(diǎn)。一個(gè)Commit對(duì)象包含指向頂層Tree對(duì)象的哈希代表本次提交的項(xiàng)目快照、指向父提交Parent Commit的一個(gè)或多個(gè)哈希用于形成歷史鏈、作者和提交者信息、以及提交信息。首次提交沒(méi)有父提交合并提交則有兩個(gè)或更多父提交。Tag對(duì)象一個(gè)Tag對(duì)象指向一個(gè)特定的Commit對(duì)象并包含標(biāo)簽名、標(biāo)簽類(lèi)型輕量標(biāo)簽或附注標(biāo)簽、打標(biāo)簽者等信息為重要的提交里程碑提供一個(gè)固定的、可讀的名字。它們的關(guān)系可以這樣理解Commit指向TreeTree指向Blob和其他Tree共同構(gòu)成一次完整的提交快照。多個(gè)Commit通過(guò)父指針串聯(lián)成歷史。分支和標(biāo)簽則是指向某個(gè)Commit的“指針”或“引用”。2.2 .git目錄探秘對(duì)象存儲(chǔ)的物理實(shí)現(xiàn)所有魔法都發(fā)生在項(xiàng)目根目錄下的.git文件夾里。理解它的結(jié)構(gòu)是掌握底層原理的關(guān)鍵。objects/目錄這是Git的對(duì)象數(shù)據(jù)庫(kù)。所有Blob、Tree、Commit、Tag對(duì)象都存儲(chǔ)在這里。為了高效Git將對(duì)象文件存儲(chǔ)在以其SHA-1哈希值前兩位命名的子目錄中后38位作為文件名。例如一個(gè)哈希為d670460b4b4aece5915caf5c68d12f560a9fe3e4的對(duì)象會(huì)被存儲(chǔ)在objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4。你可以使用git cat-file -p hash命令查看任何對(duì)象的內(nèi)容用-t查看其類(lèi)型。這是診斷倉(cāng)庫(kù)問(wèn)題的終極武器。refs/目錄這里存放著所有的“引用”。refs/heads/下是本地分支指針每個(gè)文件名為分支名內(nèi)容是一個(gè)Commit的SHA-1值。refs/tags/下是標(biāo)簽。refs/remotes/下則存儲(chǔ)著遠(yuǎn)程跟蹤分支如origin/main。HEAD文件這是一個(gè)特殊的引用文件它通常指向當(dāng)前所在的分支即refs/heads/下的某個(gè)文件其內(nèi)容形如ref: refs/heads/feature。它定義了你的工作目錄當(dāng)前是基于哪個(gè)提交進(jìn)行修改的。當(dāng)處于“分離頭指針”狀態(tài)時(shí)HEAD直接包含一個(gè)Commit的哈希值。實(shí)操心得當(dāng)你遇到“找不到對(duì)象”這類(lèi)詭異錯(cuò)誤時(shí)別慌。先去.git/objects里看看對(duì)應(yīng)的文件是否存在。有時(shí)倉(cāng)庫(kù)損壞這個(gè)目錄能給你最直接的線索。另外git fsck命令可以檢查倉(cāng)庫(kù)的完整性它會(huì)遍歷所有對(duì)象并報(bào)告損壞或丟失的情況。3. 分支合并的底層邏輯三路合并與沖突的產(chǎn)生分支合并是Git最強(qiáng)大也最容易出問(wèn)題的功能。其底層核心是“三路合并”算法。3.1 快進(jìn)合并與非快進(jìn)合并的本質(zhì)區(qū)別很多人知道git merge有兩種模式但未必清楚其底層決定因素?？爝M(jìn)合并當(dāng)你要合并的分支例如feature的尖端提交是你當(dāng)前分支例如main尖端提交的直接后代時(shí)Git會(huì)執(zhí)行快進(jìn)合并。此時(shí)Git不需要?jiǎng)?chuàng)建新的合并提交它只是簡(jiǎn)單地將當(dāng)前分支的指針如refs/heads/main向前移動(dòng)到目標(biāo)分支指向的提交。在對(duì)象層面沒(méi)有新的Commit對(duì)象產(chǎn)生只是引用被更新了。你可以通過(guò)git merge --ff-only強(qiáng)制只進(jìn)行快進(jìn)合并確保歷史線性。非快進(jìn)合并當(dāng)兩個(gè)分支的歷史已經(jīng)分叉即它們有共同的祖先但各自都有新的提交。此時(shí)Git必須進(jìn)行真正的“合并”操作。Git會(huì)找到這兩個(gè)分支的“最近共同祖先”然后基于這個(gè)祖先、當(dāng)前分支的修改、要合并分支的修改應(yīng)用三路合并算法嘗試生成一個(gè)新的合并結(jié)果。如果成功Git會(huì)創(chuàng)建一個(gè)新的“合并提交”。這個(gè)合并提交比較特殊它有兩個(gè)父提交。在.git/objects里它是一個(gè)新的Commit對(duì)象其parent字段包含了兩個(gè)SHA-1值。3.2 深入三路合并算法假設(shè)我們有三個(gè)提交Base: 分支A和分支B的共同祖先提交。Ours: 當(dāng)前分支比如main的最新提交。Theirs: 要合并的分支比如feature的最新提交。Git合并一個(gè)文件時(shí)會(huì)分別取出Base、Ours、Theirs三個(gè)版本中該文件的內(nèi)容。然后逐行比較如果Ours和Theirs相對(duì)于Base的修改是相同的那么采用任一方的修改。如果Ours修改了某處而Theirs沒(méi)動(dòng)相對(duì)于Base則采用Ours的修改。如果Theirs修改了某處而Ours沒(méi)動(dòng)則采用Theirs的修改。沖突產(chǎn)生如果Ours和Theirs都對(duì)同一處不一定是同一行但行范圍有重疊進(jìn)行了不同的修改Git無(wú)法自動(dòng)決定采用哪一個(gè)就會(huì)標(biāo)記為沖突。此時(shí)Git會(huì)將三個(gè)版本的內(nèi)容同時(shí)標(biāo)記在沖突文件中等待你手動(dòng)解決。這個(gè)過(guò)程在底層是通過(guò)對(duì)Blob對(duì)象的內(nèi)容進(jìn)行差異比較實(shí)現(xiàn)的。Git內(nèi)部有高效的差異算法如Myers差分算法來(lái)定位修改。3.3 合并策略與git merge的幕后工作git merge命令背后可以使用不同的合并策略默認(rèn)是recursive。當(dāng)遇到分叉歷史時(shí)recursive策略會(huì)先找到共同祖先如果祖先不唯一在復(fù)雜合并中可能出現(xiàn)它會(huì)先遞歸地合并這些祖先生成一個(gè)虛擬的合并基礎(chǔ)再進(jìn)行最終的三路合并這能處理一些棘手的合并情況。合并操作在底層會(huì)經(jīng)歷以下步驟定位提交根據(jù)你提供的分支名找到對(duì)應(yīng)的Commit對(duì)象Ours和Theirs及它們的共同祖先Base。計(jì)算差異分別計(jì)算Base - Ours和Base - Theirs的差異。應(yīng)用合并嘗試將這兩組差異應(yīng)用到Base版本上。如果兩組差異修改了不同的文件或同一文件的不同部分則自動(dòng)合并生成新的文件內(nèi)容新的Blob對(duì)象。創(chuàng)建Tree對(duì)象用合并后的所有文件新的Blob生成一個(gè)新的頂層Tree對(duì)象。創(chuàng)建Commit對(duì)象最后創(chuàng)建一個(gè)新的Commit對(duì)象其Tree指向步驟4生成的Tree父提交指向Ours和Theirs。然后將當(dāng)前分支的引用如refs/heads/main更新到這個(gè)新的合并提交。如果第3步遇到?jīng)_突Git會(huì)暫停將沖突標(biāo)記寫(xiě)入工作區(qū)的文件并在索引暫存區(qū)中記錄沖突狀態(tài)。此時(shí)新的Commit對(duì)象和分支引用都不會(huì)被創(chuàng)建等待你解決沖突后執(zhí)行g(shù)it add更新索引再執(zhí)行g(shù)it commit來(lái)完成合并提交的創(chuàng)建。注意事項(xiàng)很多人合并出問(wèn)題是因?yàn)樵诤喜⑶氨镜毓ぷ鲄^(qū)或暫存區(qū)有未提交的更改。這會(huì)讓情況變得復(fù)雜。一個(gè)黃金法則是在執(zhí)行任何合并操作前先通過(guò)git status確認(rèn)工作區(qū)是干凈的或者通過(guò)git stash將更改暫存起來(lái)。這能確保合并操作只處理已知的提交歷史避免引入不必要的變量。4. 項(xiàng)目推拉的核心原理引用協(xié)商與對(duì)象傳輸git push和git pull(git fetchgit merge) 是團(tuán)隊(duì)協(xié)作的命脈。其底層是本地與遠(yuǎn)程倉(cāng)庫(kù)之間對(duì)象的同步和引用的更新。4.1git fetch獲取遠(yuǎn)程更新而不打擾你git fetch origin是“拉取”操作的安全第一步。它只做兩件事獲取對(duì)象連接到遠(yuǎn)程倉(cāng)庫(kù)origin詢問(wèn)它有哪些新的對(duì)象Commit、Tree、Blob、Tag是你本地沒(méi)有的。然后將這些對(duì)象下載到你的本地.git/objects目錄中。你的工作區(qū)文件絲毫不會(huì)改變。更新遠(yuǎn)程跟蹤分支將遠(yuǎn)程倉(cāng)庫(kù)分支的最新?tīng)顟B(tài)記錄到本地的遠(yuǎn)程跟蹤分支上例如更新refs/remotes/origin/main。這個(gè)origin/main指針是一個(gè)“只讀”的引用它告訴你遠(yuǎn)程main分支最后一次已知的位置。這個(gè)過(guò)程是冪等的可以安全地頻繁執(zhí)行讓你時(shí)刻了解遠(yuǎn)程的進(jìn)展。你可以通過(guò)git log origin/main來(lái)查看遠(yuǎn)程分支的歷史與你本地的git log main進(jìn)行對(duì)比。4.2git pull的真實(shí)面目git pull本質(zhì)上等于git fetch后接一個(gè)git merge默認(rèn)行為可配置為git rebase。很多人直接git pull導(dǎo)致沖突就是因?yàn)橹豢吹搅撕喜⒌慕Y(jié)果而沒(méi)看到fetch帶來(lái)的變化。更推薦的做法是git fetch origin # 先獲取更新到本地倉(cāng)庫(kù) git log --oneline --graph --all # 圖形化查看本地和遠(yuǎn)程所有分支歷史 git merge origin/main # 或 git rebase origin/main 在清楚差異后決定如何整合這樣做給了你一個(gè)觀察和決策的機(jī)會(huì)而不是盲目地直接合并。4.3git push上傳對(duì)象與更新遠(yuǎn)程引用git push origin main是“推送”操作它試圖用你本地的狀態(tài)去更新遠(yuǎn)程倉(cāng)庫(kù)。對(duì)象打包與上傳Git會(huì)找出遠(yuǎn)程倉(cāng)庫(kù)缺少的、你本地?fù)碛械乃邢嚓P(guān)對(duì)象通常是你要推送的提交及其關(guān)聯(lián)的所有Tree和Blob將它們打包并上傳。引用更新請(qǐng)求請(qǐng)求遠(yuǎn)程倉(cāng)庫(kù)將其refs/heads/main引用更新為你本地refs/heads/main所指向的Commit。這里有一個(gè)關(guān)鍵約束遠(yuǎn)程倉(cāng)庫(kù)通常會(huì)拒絕“非快進(jìn)”的推送。也就是說(shuō)如果你本地的main分支不是遠(yuǎn)程main分支的直接后代即你本地落后于遠(yuǎn)程直接push會(huì)被拒絕提示你需要先pull。這是因?yàn)閺?qiáng)制推送會(huì)覆蓋遠(yuǎn)程的歷史可能造成團(tuán)隊(duì)其他成員的工作丟失。你可以使用git push --force或更安全的git push --force-with-lease來(lái)強(qiáng)制更新但這必須非常謹(jǐn)慎僅在確信可以覆蓋時(shí)使用比如在個(gè)人特性分支上重整提交歷史后。4.4 協(xié)議與傳輸優(yōu)化Git支持多種傳輸協(xié)議file://,git://,http(s)://,ssh://最常用的是SSH和HTTPS。在傳輸對(duì)象時(shí)Git非常智能壓縮所有對(duì)象在傳輸前都會(huì)進(jìn)行壓縮zlib。增量傳輸如果遠(yuǎn)程倉(cāng)庫(kù)已經(jīng)有類(lèi)似的對(duì)象Git會(huì)計(jì)算差異并只發(fā)送增量部分大大節(jié)省帶寬。打包文件在.git/objects/pack/目錄下你會(huì)看到.pack和.idx文件。這是Git將大量松散對(duì)象打包成二進(jìn)制包以節(jié)省空間的機(jī)制。git gc垃圾回收命令會(huì)觸發(fā)打包操作。5. 高級(jí)操作與問(wèn)題排查的底層視角理解了上述原理很多高級(jí)操作和疑難雜癥就迎刃而解了。5.1 回退、重置與歷史改寫(xiě)git reset這個(gè)命令主要操作的是當(dāng)前分支指針和索引暫存區(qū)。它有三個(gè)常用模式--soft只移動(dòng)分支指針到目標(biāo)提交索引和工作區(qū)不變。你之前的修改都處于已暫存狀態(tài)。這常用于合并多個(gè)提交為一個(gè)。--mixed默認(rèn)移動(dòng)分支指針并重置索引到目標(biāo)提交的狀態(tài)但保留工作區(qū)的文件修改。這是撤銷(xiāo)git add和提交的常用方式。--hard移動(dòng)分支指針重置索引并且徹底丟棄工作區(qū)的所有修改使其完全匹配目標(biāo)提交。危險(xiǎn)操作數(shù)據(jù)可能丟失。底層發(fā)生了什么假設(shè)你執(zhí)行g(shù)it reset --hard HEAD~1。Git會(huì)將HEAD指向的引用比如refs/heads/main的內(nèi)容從原來(lái)的Commit哈希改為HEAD~1對(duì)應(yīng)的哈希。根據(jù)新的Commit哈希讀取其對(duì)應(yīng)的Tree對(duì)象并用這個(gè)Tree對(duì)象的內(nèi)容去覆蓋當(dāng)前索引.git/index文件和工作區(qū)目錄。git revert與reset不同revert通過(guò)創(chuàng)建一個(gè)新的提交來(lái)“反做”某個(gè)舊提交的更改。這是一個(gè)安全的操作因?yàn)樗粫?huì)改變已有的公共歷史。底層就是進(jìn)行一次自動(dòng)的、反向的合并操作生成一個(gè)新的、抵消指定提交影響的Commit對(duì)象。git cherry-pick選取某個(gè)提交將其更改應(yīng)用到當(dāng)前分支。底層過(guò)程是將該提交相對(duì)于其父提交的差異計(jì)算出來(lái)然后嘗試將這些差異應(yīng)用到當(dāng)前工作目錄的基線上如果成功則創(chuàng)建一個(gè)新的提交。這本質(zhì)上是進(jìn)行一次“移植”操作。5.2 沖突解決與狀態(tài)診斷當(dāng)合并或變基發(fā)生沖突時(shí)Git會(huì)在沖突文件中插入標(biāo)記 HEAD (Current Change) 本地修改的內(nèi)容 要合并進(jìn)來(lái)的修改的內(nèi)容 branch-name (Incoming Change)同時(shí)Git提供了幾個(gè)底層工具來(lái)幫助你git status查看沖突文件列表。git diff不帶參數(shù)比較工作區(qū)和暫存區(qū)。git diff --ours比較沖突文件中“我們的”版本與基礎(chǔ)版本git diff --theirs比較“他們的”版本。git ls-files -u顯示處于沖突狀態(tài)的文件及其對(duì)應(yīng)的各個(gè)階段base, ours, theirs的Blob對(duì)象的哈希。你可以用git show hash查看任意一個(gè)版本的純凈內(nèi)容。git checkout --ours/--theirs file直接使用我們或他們的版本來(lái)整個(gè)文件覆蓋工作區(qū)文件這是一個(gè)快速解決沖突的“核選項(xiàng)”使用前確保你了解后果。5.3 常見(jiàn)疑難雜癥解析cannot retrieve latest commit at this time這通常是網(wǎng)絡(luò)問(wèn)題或遠(yuǎn)程倉(cāng)庫(kù)如GitHub暫時(shí)不可用。首先檢查網(wǎng)絡(luò)其次用git remote -v確認(rèn)遠(yuǎn)程地址正確最后可以嘗試git fetch --verbose查看詳細(xì)錯(cuò)誤信息。有時(shí)也可能是本地Git版本過(guò)舊與遠(yuǎn)程服務(wù)不兼容。分離頭指針狀態(tài)當(dāng)你用git checkout commit-hash直接檢出一個(gè)提交時(shí)就進(jìn)入了此狀態(tài)。此時(shí)HEAD文件直接包含一個(gè)哈希值而不是一個(gè)分支引用。在此狀態(tài)下做的提交不會(huì)屬于任何分支容易被垃圾回收掉。解決方法基于這個(gè)提交創(chuàng)建一個(gè)新分支 (git branch new-branch-name)。誤操作恢復(fù)Git幾乎不會(huì)丟失數(shù)據(jù)因?yàn)閷?duì)象一旦創(chuàng)建就存儲(chǔ)在.git/objects里。誤reset --hard或誤刪分支后可以通過(guò)git reflog查看所有引用變更歷史找到之前的提交哈希然后git checkout -b branch-name lost-commit-hash恢復(fù)。reflog是你本地操作的“救命稻草”。合并時(shí)“Already up to date”或“Nothing to merge”這表示你要合并的分支的所有提交都已經(jīng)包含在當(dāng)前分支的歷史中了。可能你理解的分叉并不存在或者你已經(jīng)合并過(guò)了。推送被拒絕non-fast-forward這是最常遇到的問(wèn)題。根本原因是你的本地分支落后于遠(yuǎn)程分支。必須先用git fetch獲取遠(yuǎn)程更新然后用git merge或git rebase將遠(yuǎn)程的修改整合到你的本地分支解決可能的沖突后才能再次推送。永遠(yuǎn)不要在不理解原因的情況下使用--force。6. 高效工作流與最佳實(shí)踐建議基于底層原理可以構(gòu)建更穩(wěn)健高效的工作習(xí)慣。6.1 分支策略選擇功能分支工作流每個(gè)新功能或修復(fù)都在獨(dú)立的分支feature/xxx上開(kāi)發(fā)。完成后通過(guò)Pull Request或Merge Request發(fā)起合并到主分支的請(qǐng)求。這隔離了開(kāi)發(fā)中的代碼便于代碼審查。底層原理上這創(chuàng)造了大量的短期分支合并時(shí)通過(guò)三路合并算法集成。Git Flow一個(gè)更復(fù)雜、更結(jié)構(gòu)化的模型定義了master,develop,feature,release,hotfix等長(zhǎng)期分支的角色。適合有固定發(fā)布周期的大型項(xiàng)目。其底層是頻繁地在不同分支間進(jìn)行合并操作。GitHub Flow / Trunk Based Development提倡在主干main上進(jìn)行持續(xù)集成通過(guò)短生命周期的特性分支和頻繁合并來(lái)工作。這對(duì)團(tuán)隊(duì)協(xié)作和自動(dòng)化測(cè)試要求高但能減少長(zhǎng)期分支合并帶來(lái)的巨大沖突。選擇哪種取決于團(tuán)隊(duì)規(guī)模和發(fā)布節(jié)奏。核心是讓分支的創(chuàng)建和合并變得簡(jiǎn)單、頻繁、可追溯。6.2 提交規(guī)范與歷史整潔混亂的提交歷史是協(xié)作的噩夢(mèng)。理解Commit對(duì)象的結(jié)構(gòu)后你就知道一個(gè)好的提交信息多么重要。使用約定式提交例如feat:,fix:,docs:,style:,refactor:,test:,chore:等前綴。這能自動(dòng)生成變更日志。原子性提交一次提交只做一件事。這使得回退、挑選cherry-pick和定位問(wèn)題變得極其容易。在底層一個(gè)干凈的Tree對(duì)象對(duì)應(yīng)一個(gè)清晰的功能變更。善用交互式變基git rebase -i是整理本地提交歷史的利器。它可以合并、拆分、重排、修改提交信息。但切記只對(duì)尚未推送到公共倉(cāng)庫(kù)的提交進(jìn)行變基。因?yàn)樽兓鶗?huì)改變提交的哈希值重寫(xiě)歷史會(huì)給他人的協(xié)作帶來(lái)災(zāi)難。6.3 工具與配置優(yōu)化圖形化工具像Sourcetree、GitKraken、IDE內(nèi)置的Git工具它們將底層命令可視化非常適合查看復(fù)雜的歷史圖譜、進(jìn)行拖拽合并等操作。但它們只是外殼核心邏輯與命令行一致。別名配置在~/.gitconfig中設(shè)置別名可以極大提升效率。例如[alias] co checkout br branch ci commit st status lg log --oneline --graph --decorate --all last log -1 HEAD --stat全局忽略文件創(chuàng)建~/.gitignore_global文件配置操作系統(tǒng)或編輯器生成的垃圾文件如.DS_Store,*.swp,.idea/然后在全局配置中引用它git config --global core.excludesfile ~/.gitignore_global。理解Git的底層原理不是讓你去死記硬背SHA-1哈希值而是讓你在遇到問(wèn)題時(shí)能像偵探一樣通過(guò).git目錄和一系列底層命令 (cat-file,ls-tree,rev-parse,show-ref) 看清真相。它讓你從被動(dòng)的命令執(zhí)行者變?yōu)橹鲃?dòng)的版本管理設(shè)計(jì)者。下次當(dāng)你再執(zhí)行g(shù)it merge時(shí)你腦海里浮現(xiàn)的將不再是黑盒而是一幅清晰的、由對(duì)象、樹(shù)和引用構(gòu)成的拓?fù)鋱D以及一個(gè)正在努力計(jì)算最佳合并路徑的三路合并算法。這種掌控感才是高效、自信地進(jìn)行軟件開(kāi)發(fā)的基石。