我的 git 組態檔為 origin 指定了以下 refspec：
fetch = refs/heads/rschmidtner/*:refs/remotes/origin/rschmidtner/*
git ls-remote --heads | grep rschmidtner顯示我有六個分支。這些分支也被列在.git/FETCH_HEAD檔案中。
為什么.git/refs/remotes/origin/rschmidtner只包含三個參考，甚至在我通過git fetch origin獲取之后？
uj5u.com熱心網友回復：
對你問題的簡短回答是，參考文獻不再總是單獨存盤在檔案中。
Git最初的設計正是如此：一個常規的參考，如分支名或遠程跟蹤名，只是refs/目錄中的一個檔案。 如果refs/heads/master存在，它就是一個包含一個哈希ID的檔案，因此這個哈希ID就是master分支的提示提交。 當遠程和遠程跟蹤名稱被發明時，refs/remotes/origin將根據需要包含目錄和/或檔案，以容納像refs/remotes/origin/rschmidtner/foo這樣的名稱。
這種東西仍然存在，但它有幾個缺點：
如果標簽以這種方式存盤，擁有數萬個標簽的存盤庫（例如Chromium）會導致不良行為（例如 "用完所有的inodes"）。
在典型的Windows和macOS系統上，一個名為
fred的分支和一個名為Fred的分支會被混淆，盡管Git本身假設這是兩個不同的分支名稱--在Linux服務器上它們是。最后--盡管有意向在無限期的未來保留這一點，以避免給更老的Git版本帶來問題--這意味著不可能同時擁有名為
hello和hello/world的分支。這將要求檔案系統同時存盤一個名為refs/heads/hello的檔案和一個名為refs/heads/hello的目錄，其中包含一個名為world的檔案。當有人創建了
refs/heads/fred，然后決定在他們的Linux系統上添加refs/heads/Fred/one，refs/heads/Fred/two，等等，這個特殊的問題與案例折疊問題（第二個要點）相結合。 它在那里作業得很好，而在案例折疊的土地上卻造成了痛苦。。
當前版本的 Git 以一種混合的方式存盤 ref 名稱：在 .git 中有一個名為 packed-refs 的檔案，其中包含以新行結尾的行，每行列出一個 ref 或 "peeled ref" 名稱和哈希 ID。 剝離值對標簽很有用，因為標簽通常指向標簽物件，而標簽物件又指向提交：這樣，Git就可以立即找到提交，而不必間接通過一個或多個標簽物件。 (如果R存在一個打包的參考檔案，而同一參考檔案R存在一個未打包的檔案，那么未打包的檔案將覆寫打包的參考檔案：這樣，Git在更新分支名稱時可以不考慮打包的參考檔案，例如。
未來版本的Git可能會有一個真正的refs資料庫，而不是這個名為packed-refs的相當俗氣的平面檔案 "資料庫"。 到那時，即使是更新一個 ref 的行為也不會創建一個檔案系統級的檔案。 這將巧妙地解決所有列出的缺點，同時創造一個新的缺點：即你將不能再僅僅創建檔案。
那么我怎樣才能找到我的參考文獻呢？
使用規定的 API。git for-each-ref用于列出，同時以編程方式讀取數值，git branch和git tag用于以人類身份查看它們。 使用git symbolic-ref來讀取或寫入單獨的符號參考-目前這意味著HEAD和refs/remotes/remote/HEAD只有1，以及git upd-ref來改變存盤在一個或多個參考的值。 使用 git rev-parse 來讀取特定 ref 的值；請密切關注這里的檔案，因為有很多有用的東西你可以讓 Git 為你做 during rev-parse 操作。
不要依賴檔案的存在，因為在某些情況下它們已經不存在了。
1符號參考是一個包含另一個參考的名稱的參考。 Git最初只對HEAD做了這個處理，把它變成了一個符號鏈接。 由于符號鏈接在某些系統上并不存在，Git不得不適應，將其改為包含另一個參考文獻名稱的檔案。 長期以來，用于處理這些問題的Git源代碼一直有點古怪，如果你把一個看起來正常的參考文獻名稱變成了一個符號參考文獻，它偶爾會表現失常。 例如，洗掉一個名為indir的分支，它實際上是一個名為b的分支的符號參考，將洗掉b而不是indir。
這些奇怪的現象有些已經被修復了，但除非你打算找到并修復其余的，否則最明智的做法是避免使用Git直接支持的符號參考，即特殊的HEAD名稱。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/308167.html
標籤：