標題：我如何教 Git

發表：真實

描述：

標籤： git, 學習

canonical_url：https://blog.ltgt.net/teaching-git/

封面圖片：https://marklodato.github.io/visual-git-guide/conventions.svg.png

使用 100:42 的比例以獲得最佳效果。

發佈時間: 2023-11-26 19:17 +0000

我使用 Git 已經十幾年了。八年前，我必須為一家即將建立開源專案的合作夥伴公司舉辦有關 Git（和 GitHub）的培訓課程，我將在這裡向您介紹我的教學方式。順便說一句，從那時起，我們在工作中建立了使用相同（或類似）方法的內部培訓課程。話雖如此，我並沒有發明任何東西：這很大程度上受到了其他人之前寫的內容的啟發，包括[the Pro Git book](https://git-scm. com/book/)，儘管順序不同，但 IMO 可以有所作為。

我寫這篇文章的原因是，多年來，我不斷看到人們實際上使用 Git，但沒有真正理解他們在做什麼；他們正在使用 Git。他們要么被鎖定在一個非常具體的工作流程中，他們被告知要遵循，並且無法適應另一個開源專案正在使用的工作流程（這也適用於開源維護人員並不真正了解外部貢獻者如何使用 Git） ），或者如果任何事情沒有按照他們想像的方式執行，或者他們在呼叫Git 命令時犯了錯誤，他們就會完全迷失。我受到 Julia Evans 對 Git 的（更新）興趣的啟發而寫下來，因為她有時會在社交網絡上徵求評論。

我的目標不是真正教你有關 Git 的知識，而是更多地分享我教授 Git 的方法，以便其他可能會教導的人從中獲得靈感。因此，如果您正在學習 Git，那麼這篇文章並不是專門為您而寫的（抱歉），因此可能不是自給自足的，但希望其他學習資源的連結足以填補空白，使其成為也是有用的學習資源。如果您是視覺學習者，這些外部學習資源都是有插圖的，甚至是視覺學習的。

心理模型

一旦我們清楚了為什麼我們使用VCS（版本控制系統）來記錄commits 中的更改（或者換句話說，我們將我們的更改提交到歷史記錄；我假設你對這個術語有一定的熟悉），讓我們多了解一下Git具體來說。

我認為理解 Git 至關重要的一件事是獲得其背後概念的準確心理模型。

首先，這並不是很重要，但Git 實際上並沒有記錄changes，而是記錄我們文件的snapshots（至少在概念上是這樣；它將使用packfiles 來有效地儲存內容，並且在某些情況下方實際上會儲存changes –diffs–），並且會按需產生差異。不過，這有時會顯示在某些命令的結果中（例如為什麼某些命令顯示一個檔案被刪除而另一個檔案被加入，而其他命令顯示一個檔案被重新命名）。

現在讓我們深入探討一些 Git 概念，或是 Git 如何實現一些常見的 VCS 概念。

犯罪

Git commit 是：

• 一個或多個父親提交，或第一次提交沒有父親提交 (root)

• 提交訊息

• 作者和作者日期（實際上是帶有時區偏移的時間戳）

• 提交者和提交日期

• 和我們的檔案：相對於儲存庫根的路徑名、mode（UNIX 檔案系統權限）及其內容

每次提交都會獲得一個標識符，該標識符是透過計算該資訊的 SHA1 雜湊值確定的：更改逗號，您將獲得不同的 SHA1，即不同的提交物件。 (Fwiw，Git 正在慢慢轉向 SHA-256 作為哈希功能）。

旁白：SHA1 是如何計算的？

Git 的儲存是內容尋址，這表示每個物件都使用直接從其內容派生的名稱進行存儲，並採用 SHA1 雜湊的形式。

從歷史上看，Git 將所有內容儲存在文件中，我們仍然可以這樣推理。文件的內容儲存為 blob，目錄儲存為 tree（一個文字文件，列出目錄中的文件及其名稱、模式和表示其內容的 blob 的 SHA1，以及其子目錄及其名稱和 SHA1他們的樹）

如果您想了解詳細訊息，Julia Evans（再次）寫了一篇令人驚嘆的[博客文章](https://jvns.ca/blog/2023/09/14/in-a-git-repository-- where-do-your-檔案-即時-/);或者您可以從 Pro Git 書中閱讀。

<圖>

</圖>

commit 中的父親提交 建立一個代表我們歷史的有向無環圖：有向無環圖 由連結的節點（我們的提交）組成與有向邊一起（每個提交連結到其父提交，有一個方向，因此directed）並且不能有循環/循環（提交永遠不會是它自己的祖先，它的祖先提交都不會連結到它作為父提交）。

<圖>

</圖>

參考文獻、分支和標籤

現在 SHA1 哈希對於人類來說是不切實際的，雖然 Git 允許我們使用唯一的 SHA1 前綴而不是完整的 SHA1 哈希，但我們需要更簡單的名稱來引用我們的提交：輸入 references。這些是我們選擇的提交的標籤（而不是 Git）。

有幾種參考：

• branches 是moving 引用（請注意，main 或master 並不特殊，它們的名稱只是一個約定）

  *_標籤_是_不可變_引用

• HEAD 是一個特殊的引用，指向當前提交。它通常指向一個分支而不是直接指向一個提交（稍後我們會看到原因）。當一個引用指向另一個引用時，這稱為符號引用。

• Git 會在某些操作期間為您設定其他特殊參考（FETCH_HEAD、ORIG_HEAD 等）

<圖>

</圖>

三個狀態

當您在 Git 儲存庫中工作時，您在 Git 歷史記錄中操作和記錄的檔案位於您的工作目錄中。要建立提交，您需要在 index 或暫存區域中暫存檔案。完成後，您附加一則提交訊息並將您的staged檔案移至history。

為了關閉循環，工作目錄是根據歷史記錄中的給定提交進行初始化的。

<圖>

</圖>

旁白：忽略文件

並非所有檔案都需要追蹤歷史記錄：由建置系統（如果有）產生的檔案、特定於您的編輯器的檔案以及特定於您的作業系統或其他工作環境的檔案。

Git 允許定義要忽略的檔案或目錄的命名模式。這實際上並不意味著Git 會忽略它們並且無法跟踪，但如果不跟踪它們，多個Git 操作將不會向您顯示它們或操縱它們（但您可以手動將它們加入到歷史記錄中，並且從那時起，他們將不再被忽略）。

忽略檔案是透過將路徑名稱（可能使用 glob）放入忽略檔案中來完成的：

• 儲存庫中任何位置的 .gitignore 檔案定義了包含目錄的忽略模式；這些忽略文件會在歷史記錄中被跟踪，作為開發人員之間共享它們的一種方式；在這裡，您將忽略建置系統產生的那些檔案（Gradle 專案的“build/”，Eleventy 網站的“_site/”等）

• .git/info/excludes 是您機器上的本機儲存庫；很少使用，但有時很有用，所以很高興了解一下

• 最後 ~/.config/git/ignore 對機器來說是全域的（對你的使用者）；在這裡，您將忽略特定於您的電腦的文件，例如特定於您使用的編輯器的文件，或特定於您的作業系統的文件（例如macOS 上的“.DS_Store”或Windows 上的“Thumbs. db”） ）

加起來

這是所有這些概念的另一種表示：

<圖>

如需更多詳細資訊和視覺表示，請參閱commit 和[checkout](https://marklodato. github .io/visual-git-guide/index-en.html#checkout）Mark Lotato 的可視化Git 參考的部分（請注意，該參考是幾年前寫的，當時git switch 和 git Restore 不存在，而 git checkout 是我們所擁有的一切；因此 checkout 部分涵蓋的內容比 git switch 多一點）。

當然，Pro Git 這本書也是一個很好的視覺表示參考； Branches in a Nutshell 子章節 涵蓋了所有內容的很大一部分上述的。

旁白：Git 是保守的

正如我們在上面所看到的，由於其內容尋址存儲，對提交的任何“更改”（例如使用“git commit --amend”）實際上都會導致不同的提交（不同的 SHA1）。 舊提交不會立即消失：Git 使用垃圾收集最終刪除無法從任何引用存取的提交。這意味著，如果您設法找回提交SHA1，則可以恢復許多錯誤（“git reflog”可以在此處提供幫助，或者符號“@{}”，例如“main@{ 1}”） main 在更改之前指向的最後一次提交）。

使用分支機構

我們在上面已經看到了分支是如何發散的。

但分歧要求最終合併變回來（使用“git merge”）。 Git 在這方面非常擅長（我們稍後會看到）。

合併的一個特殊情況是目前分支是要合併到的分支的祖先。在這種情況下，Git 可以執行 fast-forward merge。

由於兩個分支之間的操作可能始終針對同一對分支，因此 Git 允許您設定一個分支來追蹤另一個分支。另一個分支被稱為追蹤它的分支的上游。例如，設定時，「git status」將告訴您兩個分支彼此之間有多少分歧：目前分支是[最新](https://blog.ltgt.net/confusing-git-terminology /#your- branch-is-up-to-date-with-originmain) 及其上游分支，後面和[可以快轉](https://blog.ltgt.net/confusing-git-terminology/ #can-be- fast-forwarded），超前許多提交，或它們有分歧，每個提交都有一定數量。其他命令將使用該資訊為參數提供良好的預設值，以便可以省略它們。

要整合來自另一個分支的更改，而不是合併，另一種選擇是cherry-pick（使用同名命令）單一提交，而不包含其歷史記錄：Git 將計算該提交帶來的更改並將相同的更改應用於當前分支，建立一個與原始分支類似的新提交（如果您想了解更多有關Git 實際操作方式的訊息，請參閱Julia Evans 的如何gitcherry-pick 和revert 使用3 路合併< /cite> )。

最後，工具帶中的另一個指令是「rebase」。

您可以將其視為一次進行許多選擇的方法，但它實際上更強大（正如我們將在下面看到的）。但在其基本用途中，它只是這樣：您給它一系列提交（在作為起點的任何提交和作為終點的現有分支之間，預設為當前分支）和一個目標，並且它會挑選所有這些提交位於目標之上，並最終更新用作終點的分支。這裡的指令的形式是git rebase --onto=<target> <start> <end>。與許多 Git 命令一樣，參數可以省略，並且具有預設值和/或特定含義：因此，git rebase 是 git rebase --fork-point upper 的簡寫，其中 upstream 是 [upstream]當前分支的（https://blog.ltgt.net/confusing-git-terminology/#untracked-files-remote-tracking-branch-track-remote-branch）（我會忽略--fork-point這裡，它的作用很微妙，在日常使用上並不那麼重要），它本身就是git rebase upper HEAD 的簡寫（其中HEAD 必須指向一個分支），它本身就是git rebase 的簡寫-- on=upstream uploaded，git rebase --onto=upstream $(git merge-baseupstream HEAD) HEAD 的簡寫，並將rebase upstream 的最後一個共同祖先與當前分支之間的所有提交另一方面，手和當前分支（即自從它們分歧以來的所有提交），並將它們重新應用到“上游”之上，然後更新當前分支以指向新的提交。明確使用--onto （其值與起始點不同）實際上很少見，請參閱[我之前的文章](https://blog.ltgt.net/confusing-git-terminology/#git- rebase- --onto) 對於一個用例。

我們無法在沒有互動式變體「git rebase -i」的情況下呈現「git rebase」：它以與非互動式變體完全相同的行為開始，但在計算需要完成的操作之後，它將允許您對其進行編輯（作為編輯器中的文字文件，每行一個操作）。預設情況下，所有選定的提交都是精心挑選的，但您可以對它們重新排序，跳過某些提交，甚至將某些提交合併到單一提交中。實際上，您可以挑選最初未選擇的提交，甚至建立合併提交，從而完全重寫整個歷史記錄！最後，您還可以停止對其進行編輯（然後使用“git commit --amend”，和/或可能在繼續變基之前建立新的提交），和/或在兩次提交之間執行給定的命令。最後一個選項非常有用（例如，驗證您沒有在歷史記錄的每個點上破壞您的專案），您可以在--exec 選項中傳遞該命令，Git 將在每個重新基底提交之間執行它（這也適用於非互動式變基；在互動模式下，當能夠編輯變基場景時，您將看到在每個櫻桃選擇行之間插入執行行）。

更多詳細資訊和視覺表示，請參閱merge、[cherry pick](https://marklodato . github.io/visual-git-guide/index-en.html#cherry-pick) 和 rebase Mark Lodato 的視覺化Git 參考 部分，以及[基本分支和合併](https://git-scm.com/book/en/v2/Git-分支-基本-分支和合併），[變基]（https://git-scm.com/book/en/v2/Git-Branching-Rebasing）和重寫歷史< /cite> Pro Git 書的子章節。

您也可以查看 David Drysdale 的 Git Visual Reference 中的「分支和合併」圖。

與他人合作

目前，我們只在我們的儲存庫中進行本地工作。

但 Git 是專門為與他人合作而建構的。

讓我介紹一下遙控器。

遙控器

當您複製儲存庫時，該儲存庫將成為本機儲存庫的遠端，名為「origin」（就像「main」分支一樣，這只是預設值，名稱本身沒有什麼特別的，除了有時用作省略命令參數時的預設值）。然後，您將開始工作，建立本地提交和分支（因此從遠端forking），同時遠端可能會從其作者那裡獲得更多提交和分支。因此，您需要將這些遠端變更同步到本機儲存庫，並希望快速了解與遠端相比您在本機所做的變更。 Git 處理這個問題的方式是在一個特殊的命名空間中記錄它所知道的遠端（主要是分支）的狀態：「refs/remote/」。這些被稱為遠端追蹤分支。 Fwiw，本機分支儲存在「refs/heads/」命名空間中，標籤儲存在「refs/tags/」中（來自遠端的標籤通常直接「匯入」到「refs/tags/」中，因此例如您會遺失位置資訊他們來自）。您可以根據需要擁有任意多個遙控器，每個遙控器都有一個名稱。 （請注意，遙控器不一定位於其他電腦上，它們實際上可以位於同一台電腦上，直接從檔案系統存取，因此您無需進行任何設定即可使用遙控器。）

取得

每當你從遠端 fetch 時（使用 git fetch、git pull 或 git Remote update），Git 都會與它對話以下載它還不知道的提交，並更新 remote-tracking遠端分支 。要取得的確切引用集以及取得它們的位置將傳遞給 git fetch 命令（如 refspecs ）以及儲存庫的.git/config 中定義的預設值，預設由git clone 或git remote add 配置以取得所有分支（遠端上的refs/heads/ 中的所有內容）並放置它們位於refs/remote/<remote> 中（因此origin 遙控器的refs/remote/origin/ ）具有相同的名稱（因此遙控器上的refs/heads/main 變成refs/remote / origin/main 本地）。

<圖>

與「git fetch」一樣，您可以將要更新的分支傳遞給「git push」命令，但如果您不這樣做，Git 會提供良好的預設行為。如果你不指定任何東西，Git 會從目前分支的上游推斷遠程，所以大多數時候 git push 相當於 git push origin。這實際上是“git Push origin main”的簡寫（假設當前分支是“main”），它本身是“git Push origin main:main”的簡寫，是“git Push origin refs/heads/main:refs/”的簡寫heads/main，意思是將本地的refs/heads/main推送到origin遠端的refs/heads/main`。有關使用不同來源和目標指定 refspecs 的一些用例，請參閱我之前的文章。

<圖>

<

figcaption>git Push（資料來源：Git 視覺參考，David Drysdale ）</圖標題>

</圖>

更多詳細資訊和視覺表示，請參閱遠端分支，< cite >使用遙控器，以及為專案做出貢獻</ cite> Pro Git 書的子章節，以及「處理遠程來自David Drysdale 的Git Visual Reference 的「儲存庫」圖表。

Pro Git 的為專案做出貢獻一章也涉及在GitHub 等平台上為開源專案做出貢獻，您必須先fork儲存庫，然後透過pull requests進行貢獻（或合併請求）。

最佳實踐

這些是針對初學者的，希望不會引起太多爭議。

嘗試保留clean歷史記錄：

• 明智地使用合併提交

• 清晰且高品質的提交訊息（請參閱[提交指南](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project #_commit_guidelines）在Pro Git 中）

• make atomic commits：每個提交應該獨立於歷史記錄中跟隨它的提交進行編譯和執行

這僅適用於您與他人分享的歷史記錄。

在本地，想怎麼做就怎麼做。對於初學者，我會給以下建議：

• 不要直接在“main”（或“master”，或您在遠端上沒有專門擁有的任何分支）上工作，而是建立本機分支；它有助於解耦不同任務的工作：即將開始處理另一個錯誤或功能，同時等待有關當前任務的說明的更多詳細資訊？切換到另一個分支，稍後您可以透過切換回來回到該分支；它還使從遠端更新變得更容易，因為如果您的本地分支只是同名遠端分支的副本，沒有任何本地更改（除非您想推送這些更改），您確信不會發生衝突到該分支）

• 毫不猶豫地重寫你的提交歷史記錄（git commit --amend 和/或 git rebase -i），但不要太早這樣做；在工作時堆疊許多小提交是完全可以的，並且只在共享之前重寫/清理歷史記錄

• 同樣，請毫不猶豫地重新調整本機分支以整合上游變更（直到您共用該分支，此時您將遵循專案的分支工作流程）

如果出現任何問題並且您迷路了，我的建議是使用 gitk 或 gitk HEAD @{1}，也可能使用 gitk --all （我在這裡使用 gitk 但使用任何工具你喜歡），可視化你的Git 歷史並嘗試了解發生了什麼。由此，您可以回滾到先前的狀態（git reset @{1}）或嘗試修復問題（擇優選擇提交等）。合併失敗，您可以使用“git rebase --abort”或“git merge - -abort」等命令中止並回滾到先前的狀態。

為了讓事情變得更簡單，請不要猶豫，在任何可能具有破壞性的命令（git rebase）之前，建立一個分支或標籤作為“書籤”，如果事情沒有按預期進行，您可以輕鬆重置。當然，在執行這樣的命令後，請檢查歷史記錄和文件，以確保結果是您所期望的。

進階概念

這只是其中的一小部分，還有更多值得探索！

• 分離的「HEAD」：git checkout 手冊頁 有一個關於該主題的很好的部分，另請參閱[我之前的帖子](https ://blog.ltgt.net/confusing-git-terminology/#detached-head-state），要獲得良好的視覺表示，請參閱[使用分離的HEAD 進行提交</ cite>](https:// /marklodato.github.io/visual-git-guide/index-en.html#detached) Mark Lodato 的 視覺化 Git 參考 部分。

• Hooks：這些是可執行檔（大多數情況下是 shell 腳本），Git 將執行它們來回應儲存庫上的操作；人們使用它們在每次提交之前檢查程式碼（如果失敗則中止提交），產生或後處理提交訊息，或在有人推送到儲存庫後觸發伺服器上的操作（觸發建置和/或部署）。

• 一些很少需要的命令可以在您真正需要時節省您的時間：

  • git bisect：一個進階命令，透過測試多個提交（手動或透過腳本）來幫助您找出哪個提交引入了錯誤；對於線性歷史，這是使用二分法並且可以手動完成，但是一旦您有許多合併提交，這就會變得更加複雜，並且最好讓 git bisect 來完成繁重的工作。

  • git filter-repo：實際上是一個第三方命令，作為Git 自己的filter-branch 的替代品，它允許重寫儲存庫的整個歷史記錄，以刪除錯誤新增的文件，或協助將儲存庫的一部分提取到另一個儲存庫。

我們完成了。

有了這些知識，人們應該能夠將任何 Git 命令映射到如何修改提交的有向無環圖，並了解如何修復錯誤（在錯誤的分支上執行合併？基於錯誤的分支重新建置？）並不是說理解這些事情會很容易，但至少應該是可能的。

原文出處：https://dev.to/tbroyer/how-i-teach-git-3nj3