1. 項(xiàng)目概述為什么我們需要一份自己的Git命令備忘錄干了這么多年開發(fā)我電腦里一直存著一個(gè)叫“git_cheatsheet.md”的文件。它不是什么高深的秘籍就是我自己整理的一份Git常用命令和踩坑記錄。每次換新電腦、帶新人或者隔了幾個(gè)月沒碰某個(gè)復(fù)雜流程我都會(huì)把它翻出來看看。我發(fā)現(xiàn)無論你是剛?cè)胄械男率诌€是像我這樣摸爬滾打多年的老鳥手邊有這么一份“接地氣”的、帶注釋和解決方案的清單效率提升不是一點(diǎn)半點(diǎn)。網(wǎng)上Git教程浩如煙海但真到了關(guān)鍵時(shí)刻——比如合并沖突時(shí)手忙腳亂或者想撤銷一個(gè)已經(jīng)推到遠(yuǎn)程的提交時(shí)——你往往沒時(shí)間去從頭翻看教程。你需要的是能直接“抄作業(yè)”的命令以及這個(gè)命令背后“為什么”這么用還有“用了會(huì)怎樣”的實(shí)操心安。這份記錄就是要把那些高頻、關(guān)鍵且容易出錯(cuò)的Git操作從“知道”變成“熟練”再?gòu)摹笆炀殹鄙A到“理解”。它不追求大而全只聚焦于那些在真實(shí)項(xiàng)目協(xié)作中能真正幫你省時(shí)間、避大坑的場(chǎng)景。2. 核心思路如何構(gòu)建一份高效的Git操作指南我的這份記錄核心思路就三點(diǎn)場(chǎng)景驅(qū)動(dòng)、命令解釋、問題前置。它不是按字母順序羅列命令而是圍繞一個(gè)開發(fā)者日常的工作流來組織。2.1 場(chǎng)景驅(qū)動(dòng)從“做什么”倒推“用什么”我不會(huì)一上來就講git init。而是假設(shè)你此刻要開始一個(gè)新功能開發(fā)你會(huì)經(jīng)歷克隆項(xiàng)目 - 創(chuàng)建分支 - 寫代碼 - 暫存提交 - 推送 - 發(fā)起合并請(qǐng)求。我的命令清單就跟著這個(gè)流程走。這樣當(dāng)你處于“我要開始寫新功能了”這個(gè)場(chǎng)景時(shí)你能立刻找到對(duì)應(yīng)區(qū)塊的命令連貫地執(zhí)行下去而不是東找西找。2.2 命令解釋知其然更知其所以然對(duì)于每個(gè)命令我不僅記錄語(yǔ)法更會(huì)備注上我自己的理解。比如git commit -m “msg”和git commit -v有什么區(qū)別為什么有時(shí)候推薦用-v我會(huì)寫上“-v參數(shù)會(huì)在編輯器里顯示本次提交的具體變更方便你最后確認(rèn)避免提交了不該提交的調(diào)試代碼。在提交重要改動(dòng)時(shí)強(qiáng)烈建議使用?！?這樣這條命令就從冷冰冰的代碼變成了有溫度的建議。2.3 問題前置把坑填平把路鋪好這是這份記錄價(jià)值最高的部分。我會(huì)把那些讓我栽過跟頭、或隊(duì)友常問的問題直接附在相關(guān)命令后面。比如在git push命令旁我會(huì)記錄“問題推送被拒絕提示‘非快進(jìn)式更新’。解決先執(zhí)行g(shù)it pull --rebase整合遠(yuǎn)程變更再推送。注意rebase會(huì)重寫歷史在公共分支上謹(jǐn)慎使用?！?這就把解決方案和風(fēng)險(xiǎn)提示一次性給到位了。3. 日常開發(fā)流核心命令詳解這是使用頻率最高的部分覆蓋了從獲取代碼到提交推送的完整閉環(huán)。3.1 倉(cāng)庫(kù)初始化與代碼獲取一切始于獲取代碼。除了最基礎(chǔ)的git clone url有幾個(gè)參數(shù)很實(shí)用。git clone --depth 1 url淺克隆只拉取最近一次提交的歷史。對(duì)于歷史龐大、你只需要最新代碼的倉(cāng)庫(kù)這能極大節(jié)省時(shí)間和磁盤空間。想獲取完整歷史后再執(zhí)行g(shù)it fetch --unshallow即可。git clone -b branch_name url直接克隆指定分支而不是默認(rèn)的main或master。注意新項(xiàng)目初始化時(shí)如果你是在已有代碼目錄執(zhí)行g(shù)it init記得第一時(shí)間添加.gitignore文件否則很容易把編譯產(chǎn)物、IDE配置、本地環(huán)境文件等無關(guān)內(nèi)容誤提交上去。我習(xí)慣從 gitignore.io 根據(jù)項(xiàng)目類型如Java、Node、Python生成模板。3.2 分支操作高效協(xié)作的基石分支是Git的靈魂相關(guān)命令必須熟練。git branch查看本地分支。-v參數(shù)可以查看每個(gè)分支最后一次提交信息-a查看所有本地遠(yuǎn)程分支。git checkout -b feature/xxx創(chuàng)建并切換到新分支。這是功能開發(fā)的起手式。在Git 2.23版本后更推薦使用git switch -c feature/xxx語(yǔ)義更清晰switch切換create創(chuàng)建。git branch -d branch_name刪除已合并的分支。這里有個(gè)大坑如果分支未合并此命令會(huì)失敗。有時(shí)你想強(qiáng)制刪除未合并的分支比如實(shí)驗(yàn)性分支作廢了必須使用-D大寫參數(shù)git branch -D branch_name。執(zhí)行前務(wù)必確認(rèn)分支內(nèi)容真的不需要了。git push origin --delete branch_name刪除遠(yuǎn)程分支。本地分支刪除后遠(yuǎn)程分支并不會(huì)自動(dòng)刪除需要顯式執(zhí)行此命令。3.3 狀態(tài)查看與差異比較搞清楚當(dāng)前狀態(tài)和改了什么是避免混亂的前提。git status最常用的命令務(wù)必養(yǎng)成頻繁查看的習(xí)慣。它會(huì)告訴你哪些文件被修改、哪些已暫存、哪些未被跟蹤。git diff查看工作區(qū)與暫存區(qū)的差異。git diff --staged或--cached查看暫存區(qū)與上一次提交的差異。git diff HEAD查看工作區(qū)與最新提交的差異。git log查看提交歷史。光禿禿的git log信息很快會(huì)刷屏我常用幾個(gè)組合git log --oneline --graph --all以單行、圖形化方式展示所有分支歷史一目了然。git log -p file_path查看某個(gè)文件的詳細(xì)修改歷史。git log --since”2 weeks ago”查看最近兩周的提交。3.4 暫存與提交保存你的工作進(jìn)度提交不是簡(jiǎn)單打幾個(gè)字好的提交習(xí)慣能讓歷史清晰易懂。git add .暫存所有變更。這是把雙刃劍方便但危險(xiǎn)容易把調(diào)試語(yǔ)句、臨時(shí)文件一起加進(jìn)去。更安全的做法是使用git add -p交互式暫存它會(huì)逐個(gè)片段hunk詢問你是否要暫存給你一次審查的機(jī)會(huì)。git commit -m “message”提交。提交信息怎么寫我遵循一個(gè)簡(jiǎn)單模板“類型: 簡(jiǎn)短摘要”。例如“feat: 添加用戶登錄驗(yàn)證功能”、“fix: 修復(fù)首頁(yè)圖片在移動(dòng)端顯示錯(cuò)位的問題”、“docs: 更新API接口文檔”。類型如feat、fix、docs、style、refactor等能讓歷史非常規(guī)整。git commit --amend修改上一次提交。如果你剛提交完發(fā)現(xiàn)漏了文件或者提交信息寫錯(cuò)了可以用這個(gè)命令。它會(huì)將暫存區(qū)的修改合并到上一次提交中并允許你修改提交信息。警告如果上一次提交已經(jīng)推送到遠(yuǎn)程不要輕易使用--amend除非你確定團(tuán)隊(duì)協(xié)作模式允許通常不允許因?yàn)檫@改寫了歷史。4. 代碼同步與整合處理遠(yuǎn)程協(xié)作多人協(xié)作時(shí)與遠(yuǎn)程倉(cāng)庫(kù)的同步是核心也是最容易出問題的地方。4.1 拉取與推送git pull拉取遠(yuǎn)程更新并合并到當(dāng)前分支。它相當(dāng)于git fetch獲取遠(yuǎn)程更新 git merge合并到本地。這里有個(gè)關(guān)鍵選擇git pull默認(rèn)是merge方式會(huì)產(chǎn)生一個(gè)合并提交。我更傾向于使用git pull --rebase它會(huì)將你的本地提交“變基”到遠(yuǎn)程更新之后使得歷史線保持一條直線更整潔。git push推送本地提交到遠(yuǎn)程。常用形式是git push origin branch_name。如果遠(yuǎn)程分支不存在可以用git push -u origin branch_name-u參數(shù)會(huì)建立本地分支與遠(yuǎn)程分支的追蹤關(guān)系之后直接git push即可。4.2 處理推送沖突非快進(jìn)式更新這是新手最常遇到的錯(cuò)誤之一。當(dāng)你執(zhí)行g(shù)it push時(shí)提示“! [rejected] main - main (non-fast-forward)”。這意味著遠(yuǎn)程分支已經(jīng)有了你本地沒有的新提交Git拒絕直接覆蓋。解決方案首選方案推薦git pull --rebase然后解決可能出現(xiàn)的沖突再git push。rebase會(huì)把你的提交“接”在別人提交的后面。備選方案git pull默認(rèn)merge然后解決沖突再git push。這會(huì)產(chǎn)生一個(gè)額外的合并提交。實(shí)操心得在團(tuán)隊(duì)開發(fā)中尤其是功能分支我強(qiáng)烈建議養(yǎng)成先git pull --rebase再git push的習(xí)慣。這能保持提交歷史的線性在代碼審查時(shí)更容易追蹤。但在長(zhǎng)期存在的公共分支如main上有時(shí)使用merge保留合并記錄更能反映真實(shí)的協(xié)作過程。4.3 遠(yuǎn)程倉(cāng)庫(kù)管理git remote -v查看已配置的遠(yuǎn)程倉(cāng)庫(kù)地址。git remote add upstream url在為開源項(xiàng)目貢獻(xiàn)時(shí)常用。將原始項(xiàng)目倉(cāng)庫(kù)添加為upstream上游你自己的Fork倉(cāng)庫(kù)作為origin。這樣你可以隨時(shí)從upstream同步最新代碼到本地git fetch upstream然后合并到你的分支。5. 撤銷與回退時(shí)光倒流的安全網(wǎng)人總會(huì)犯錯(cuò)Git的強(qiáng)大之處在于它提供了多級(jí)“撤銷”機(jī)制理解每一層的區(qū)別至關(guān)重要。5.1 撤銷工作區(qū)的修改還沒git addgit checkout -- file丟棄指定文件在工作區(qū)的所有修改恢復(fù)到最近一次git commit或git add時(shí)的狀態(tài)。這是一個(gè)危險(xiǎn)命令因?yàn)樗鼤?huì)永久丟棄你的修改且無法通過Git找回。執(zhí)行前請(qǐng)務(wù)必確認(rèn)。git restore fileGit 2.23版本引入的新命令作用同git checkout -- file語(yǔ)義更清晰。5.2 撤銷暫存區(qū)的修改已經(jīng)git add了git reset HEAD file將指定文件從暫存區(qū)Stage移回工作區(qū)Worktree但保留文件內(nèi)容的修改。這樣你可以重新修改或?qū)彶?。git restore --staged file同上是新命令。5.3 撤銷提交這是更復(fù)雜的操作分幾種情況情況一撤銷上一次提交但保留修改內(nèi)容在工作區(qū)。使用git reset --soft HEAD~1。這就像“撤回”了提交動(dòng)作代碼改動(dòng)還保留著你可以重新修改、暫存、提交。HEAD~1表示上一個(gè)提交。情況二撤銷上一次提交并且丟棄修改內(nèi)容。使用git reset --hard HEAD~1。這個(gè)命令極其危險(xiǎn)它會(huì)同時(shí)撤銷提交和丟棄所有工作區(qū)修改數(shù)據(jù)不可恢復(fù)。除非你100%確定這些改動(dòng)都不要了否則慎用。情況三撤銷某次特定的歷史提交但保留后續(xù)提交。使用git revert commit_hash。這個(gè)命令會(huì)創(chuàng)建一個(gè)新的提交其內(nèi)容正好是撤銷指定提交的修改。這是最安全的方式因?yàn)樗粫?huì)改寫歷史適合已經(jīng)推送到遠(yuǎn)程的提交。5.4 找回丟失的提交如果你誤操作git reset --hard刪除了還沒推送的提交別慌只要操作記錄還在大概率能找回來。使用git reflog命令。它會(huì)記錄HEAD和分支引用所有的變化歷史。找到你誤操作前的那個(gè)提交哈希值然后執(zhí)行g(shù)it reset --hard hash就能恢復(fù)。避坑指南reset --hard和checkout -- file是Git里的“核武器”威力巨大且不可逆除非用reflog搶救。我的原則是在按下回車前再執(zhí)行一次git status和git diff確認(rèn)自己要丟棄的到底是什么。對(duì)于重要的、未提交的修改養(yǎng)成先git stash儲(chǔ)藏起來的習(xí)慣給自己留條后路。6. 高級(jí)場(chǎng)景與問題排查實(shí)錄這部分是我在復(fù)雜協(xié)作和問題排查中積累的“硬核”經(jīng)驗(yàn)。6.1 儲(chǔ)藏Stash的靈活運(yùn)用git stash臨時(shí)儲(chǔ)藏工作區(qū)的改動(dòng)讓你可以切換分支或進(jìn)行其他操作事后再恢復(fù)。git stash或git stash push -m “message”儲(chǔ)藏當(dāng)前修改。加個(gè)信息是個(gè)好習(xí)慣。git stash list查看所有儲(chǔ)藏。git stash apply stash{n}應(yīng)用某個(gè)儲(chǔ)藏但不從儲(chǔ)藏列表中刪除它。git stash pop stash{n}應(yīng)用并刪除某個(gè)儲(chǔ)藏。git stash drop stash{n}刪除某個(gè)儲(chǔ)藏。git stash clear清空所有儲(chǔ)藏。場(chǎng)景你正在feature/A分支開發(fā)到一半突然需要緊急修復(fù)main分支的一個(gè)Bug。你可以1)git stash儲(chǔ)藏feature/A的改動(dòng)2)git checkout main切換分支并修復(fù)3) 修復(fù)完提交后切回feature/A執(zhí)行g(shù)it stash pop恢復(fù)現(xiàn)場(chǎng)。6.2 合并沖突的解決流程沖突不可避免冷靜處理是關(guān)鍵。觸發(fā)沖突在執(zhí)行g(shù)it merge或git pull時(shí)如果Git無法自動(dòng)合并會(huì)提示CONFLICT。查看狀態(tài)立即執(zhí)行g(shù)it status它會(huì)明確列出“Unmerged paths”沖突文件。手動(dòng)解決用編輯器打開沖突文件。Git會(huì)用標(biāo)記出沖突區(qū)域。你需要判斷保留哪邊的代碼或者進(jìn)行整合然后刪除這些標(biāo)記。標(biāo)記已解決每個(gè)沖突文件解決后執(zhí)行g(shù)it add file將其標(biāo)記為已解決。完成合并所有沖突解決并add后執(zhí)行g(shù)it commit來完成這次合并提交。Git會(huì)為你生成一個(gè)默認(rèn)的合并信息。6.3 變基Rebase的利與弊git rebase用于重新整理提交歷史使其更清晰。git rebase -i HEAD~n交互式變基最近n次提交。你可以重新排序提交、合并squash多個(gè)小提交為一個(gè)、修改提交信息等。這是一個(gè)非常強(qiáng)大的歷史整理工具。git rebase base_branch將當(dāng)前分支的提交“移植”到目標(biāo)分支的最新提交之后。優(yōu)點(diǎn)歷史線干凈、線性便于閱讀和二分查找Bug。缺點(diǎn)改寫了提交歷史。黃金法則只對(duì)你本地、尚未推送到公共倉(cāng)庫(kù)的提交進(jìn)行變基。永遠(yuǎn)不要對(duì)已經(jīng)推送到遠(yuǎn)程、可能被其他人基于其工作的提交進(jìn)行變基。6.4 常見問題速查表問題現(xiàn)象可能原因解決方案與命令git pull失敗提示需要合并本地有未提交的修改與拉取的更新沖突先git stash儲(chǔ)藏修改再git pull最后git stash pop誤提交了敏感信息如密碼、密鑰不小心add并commit了敏感文件1. 使用git filter-branch或BFG Repo-Cleaner工具從歷史中徹底刪除復(fù)雜需謹(jǐn)慎。2. 如果剛提交用git reset --soft HEAD~1撤銷提交刪除敏感信息后重新提交。想永久刪除某個(gè)文件的所有歷史記錄大文件或已刪除的依賴庫(kù)仍占用歷史空間使用git filter-branch --tree-filter ‘rm -f filename’ HEAD或?qū)Ｓ霉ぞ?。git log看不到某個(gè)分支的提交可能只在其他分支上提交了使用git log --all --graph --oneline查看所有分支歷史圖執(zhí)行命令后終端卡住無反應(yīng)可能觸發(fā)了默認(rèn)的文本編輯器如Vim等待輸入按i進(jìn)入編輯模式如果是Vim輸入信息后按Esc再輸入:wq保存退出。或設(shè)置默認(rèn)編輯器為更熟悉的git config --global core.editor “code --wait”(VS Code)這份記錄不是一成不變的它隨著我遇到的每一個(gè)新問題、學(xué)到的每一個(gè)新技巧而不斷生長(zhǎng)。Git是一個(gè)工具熟練使用它的命令只是第一步理解其背后的設(shè)計(jì)哲學(xué)快照、分支、分布式才能在復(fù)雜的協(xié)作中游刃有余。最實(shí)在的建議是在個(gè)人項(xiàng)目或?qū)嶒?yàn)分支上大膽嘗試這些命令特別是reset、rebase這些“危險(xiǎn)”操作親眼看看git status和git log的變化這比讀十篇教程都管用。當(dāng)你對(duì)時(shí)間線有了清晰的畫面感Git就不再是令人頭疼的魔法而成了你手中精準(zhǔn)的雕刻刀。