這個與來自提交的提交關聯的 git 標簽在哪里？ 如何理解版本控制歷史？

Question

我想更好地理解與標簽相關的 git 提交。

出於上下文原因，有一個名為deg/re-frame-firebase (鏈接) 的公共存儲庫。 我的懷疑實際上來自這個存儲庫的一個分支，它被稱為： tallyfor/re-frame-firebase （鏈接）

在分叉上，有這個標簽v0.10.0 。 這是關於它的信息。

有些地方我不明白。

1. 單擊與標記關聯的提交（即bd60d55 ）后，我可以看到所做的更改。 如 GitHub UI 所示，它是一個名為src/com/degel/re_frame_firebase/storage.cljs的文件的一行更改。 但是，奇怪的是我找不到這個文件。 文件路徑不存在於復刻的 master 分支上，也不存在於原始存儲庫的 master 分支上。 這個文件來自哪里？

2. 第二件事是我可以通過git checkout訪問v.0.10.0版本：

但是，標簽沒有顯示在 master 分支的git log中：

因此，由於它不在master branch上，我假設它在不同的分支上，來自 Pull Request。 但是沒有關於它的 Pull Request。

這是從哪里來的？

Answer 1

1. 任何 Git 的變更集都可以被標記
2. Tallyfor 的 repo 有很多分支
3. 為上游計划的任何功能都將在單獨的表單分支中進行編碼以實現可追溯性
4. GitHub上tag的頁面包含其分支2-fix-project-name-add-prefix-tallyfor所有信息

Answer 2

您在 Git Zen of Git 中的第一步是認識到分支和標簽無關緊要。 唯一真正重要的是提交。

單擊與標簽關聯的提交后（即bd60d55 ）

更准確地說，它是提交bd60d55815b6168210049510bb5d033301de3cb8 。

那是提交的名稱。 忘記分支名稱和標簽名稱，至少現在： bd60d55815b6168210049510bb5d033301de3cb8是提交。

如果你有一個 Git 存儲庫，並且你的 Git 存儲庫中有bd60d55815b6168210049510bb5d033301de3cb8 ，那么它就有那個提交。 地球上任何地方的任何Git 存儲庫，其中包含提交bd60d55815b6168210049510bb5d033301de3cb8的，都有該提交。 任何沒有bd60d55815b6168210049510bb5d033301de3cb8的 Git 存儲庫都沒有該提交。

如果此時你能記住bd60d55815b6168210049510bb5d033301de3cb8現在和永遠，這就是你所需要的。 但是，如果您像我一樣，即使粘貼了七次，您也可能不記得bd60d55815b6168210049510bb5d033301de3cb8了。 這就是名稱（如v0.10.0 ）有用的時候：如果你能記住它，Git 將在適當的條件下（很容易實現）使用它來找到我已經忘記的丑陋的大哈希 ID。 這將找到commit ，現在你已經完成了。 重要的是提交，Git需要哈希 ID，您可以記住標簽名稱而不是哈希 ID。

不過，奇怪的是我找不到[名為src/com/degel/re_frame_firebase/storage.cljs的文件。

在 Git 中，文件存儲在提交中。 如果你能找到提交，那就是你會找到文件的地方。 從技術上講，提交本身只包含一些元數據，這些元數據允許 Git 找到樹對象，這些對象允許 Git 將文件名轉換為 blob 哈希 ID，該 ID 可以找到包含文件內容的 blob 對象——但您不需要知道所有那。 您需要知道的是，它是提交哈希 ID 加上路徑名，讓您得到這個。

第二件事是我可以通過git checkout訪問版本v.0.10.0 ...

您可以使用git checkout或git switch --detach進入提交，這兩者都會從該特定提交的全部內容中填充您的工作樹。

在 Git 中，每個提交都包含每個文件的完整快照，及時凍結，就像提交提交時的形式一樣。

（在內部，這些存儲為通過提交找到的提交元數據找到的樹對象找到的blob 對象。這些對象本身被壓縮和去重存儲，因此每個共享某些特定數據的特定版本的提交實際上共享該文件-版本與具有相同數據的每個其他提交。此外，對象通常針對其他對象進行增量壓縮 - 但這種情況是無形的，低於提交，樹和對象存在的級別。所以你真的不需要了解所有這些：您可以放心，Git 通常可以很好地存儲每個已提交文件的每個版本，而不會浪費太多磁盤空間。）

每個提交都在其元數據中列出了一些先前（“父”）提交的哈希 ID。 在這種特殊情況下，提交bd60d55815b6168210049510bb5d033301de3cb8有一個父項，即提交432dac15092af1b8681a5cc4e69cb93433f3a5fc 。 這兩個提交中的所有文件都匹配，除了名為src/com/degel/re_frame_firebase/storage.cljs的文件，它在較新的提交中修復了一個拼寫錯誤。 許多 Git 查看器——包括git log和 GitHub 的網絡瀏覽器視圖——“喜歡”向您展示不匹配文件之間的差異，因為這通常是人們喜歡看到的。

由於 [this particular commit] 不在master branch上，我假設它在不同的分支上......

它可以在一個或多個分支上。 它可能不在任何分支上。 只要記住它的哈希ID，就可以找到它，如果不知道它的哈希ID，可以使用其他名稱來查找它。

一旦你理解了上面的內容，就該問最后幾個問題了

哲學問題：如果你找不到它，它是否存在？ （這里的“它”可能是一個提交，但這適用於代詞適合的所有內容。）

實際問題：如果它曾在某一時刻存在，但你當時找不到它，現在也找不到，Git 可能刪除了它，也可能沒有刪除它，它是否存在？

分支名稱的意義在於它們可以幫助您和 Git 找到某個分支“上”的最新提交。 任何提交都可以“在”任意數量的分支上，從“無”到無限（如果您無論如何都可以創建無限數量的分支），但是分支名稱的定義是無論它擁有什么提交哈希 ID，該提交是分支上的最新提交。 因此，無論某個分支名稱中的哈希 ID 是什么，這都是最后一次提交。 從這里開始，Git 使用存儲的父哈希 ID 來及時逆向工作。

標記名稱的意義在於它們可以幫助您和 Git 找到一個特定的提交。 這與分支名稱相同，但是：這里沒有相應的“定義”部分，附加到提交哈希 ID 的標簽並不意味着提交有任何特殊之處。 除了“一些人認為值得給出一個人類可讀的名字”。 由於這些名稱是由人類分配的，出於人類的目的，這里沒有太多要說的，只是 Git 做了一個有點微弱的嘗試來阻止人類稍后將相同的標簽名稱重新分配給不同的提交。 這種嘗試很容易被覆蓋，但如果你這樣做，請記住並不是每個人都會接受更新。 相比之下，選擇分支名稱的人應該假設分支名稱會隨着時間“移動”，因為“最新”的提交會隨着時間而變化。

你現在了解 Git 分支了！