好吧，這個讓我發瘋。我嘗試使用在另一個程式（XLS 電子表格）中打開的子模塊中的檔案提交/推送/更新父存盤庫。操作“成功”，只有一個Couldn't unlink old somefile.xls警告。
現在我正在嘗試git submodule update并且它一直指向一個舊的提交幾步。Git log在子模塊main分支上顯示這HEAD是本地和遠程的最新提交，但是每當我cd來回父存盤庫時，它都會以detached這個舊提交結束。
我嘗試手動更新.git/modules/mysubmodule/HEAD（指向這個舊提交）中的參考，但顯然這不是事情的作業方式。我怎樣才能擺脫這個令人沮喪的回圈？我想對子模塊進行一些微不足道的更改并進行新的提交可以解決它（盡管我嘗試了一個空提交但沒有運氣），但我想更好地了解發生了什么，以便將來避免這種情況。
這是我的子模塊git log：
commit 713a39e531463eb9a9a608344ca39acbe520c7c4 (HEAD -> main, origin/main, origin/HEAD)
以下是git submodule update輸出：
Submodule path 'data': checked out '7e4dc2354f5e60a8efb101a5d8a03466a911d86f'
uj5u.com熱心網友回復：
你的錯誤在于認為子模塊應該作業。??
好的，為了對子模塊和 Git 公平，讓我們這樣做：應該自動作業。子模塊可以作業，但很痛苦。（這就是為什么有些人稱它們為sob模塊。）
問題的根源在于子模塊是其他一些Git 存盤庫。此外，它通常是一個克隆一個的第三過，你可能很少或沒有控制的Git倉庫。每個 Git 存盤庫（Git 存盤庫的每個克隆）都是一個孤島。（“沒有人是一座孤島”，但每個 Git 存盤庫都是一個。）
對于要成為子模塊的 Git 存盤庫，根據定義，它必須由其他某個 Git 存盤庫控制。然而，參與其中的兩個 Git 存盤庫堅持認為它們永遠不會受到控制。所以我們有問題。
Git 對這個問題的解決方案是這樣的：
在想要控制子模塊存盤庫S的超級專案存盤庫R 中，我們放置兩件事：
- 有一個名為的檔案
.gitmodules（在每次提交中，因為檔案總是在 Git 中，因此無論您在R 中檢出哪個提交，它都在當前提交中）。此檔案列出了超級專案 Git 需要運行以創建S 的內容。git clone - 在R中使用來自S 的一些提交的每個提交中 ，有一個物體被 Git 稱為gitlink。Git 會將此物體從提交中復制到 Git 的索引/暫存區中。
- 有一個名為的檔案
一旦子模塊S存在——無論是你自己創建的，還是讓在R 中運行的 Git 命令創建它——我們都會讓你在 R 中運行的 Git 命令在S中運行。
git switch --detach hash
這意味著R負責在S 中使用哪個提交。 您在R中所做的每個提交都列出了S中將與R 中的該提交一起使用的確切提交哈希 ID 。
跑步：
git submodule update
（沒有其他選項）是控制R的 Git 命令的指令，它們應該：
- 從R的索引/暫存區讀取S的哈希 ID ；
- 使用該哈希 ID在S 中運行。
git switch --detach hash
在您更改那里的哈希 ID 之前，git submodule update將繼續檢查該特定提交。
另一方面，運行：
git submodule update --remote
意味著非常不同的東西。這里，運行在R中的Git進入S運行：
git fetch
這導致在GIT操作小號接觸到Git的從小號首先克隆（小號的origin），看看有什么新的提交，他們有一個小號沒有。這些新提交進入您在本地擁有的S克隆。它們還沒有被使用，但現在它們存在。該git fetch操作還會更新各種遠程跟蹤名稱，例如origin/main和origin/xyzbranch在您的克隆S 中。
完成后，代表R運行的 Git 將執行：
git rev-parse origin/main
或任何其他名字您選擇，找出犯小號的origin的main識別，通過哈希ID。該哈希 ID，無論它是什么，現在都與通常的一起使用：
git switch --detach <hash>
所以S的當前提交現在是他們origin/main或其他人找到的提交。
該提交在S 中檢出，但未在R 中的任何地方列出。在R 中 運行git submodule status或將顯示S與R的索引/暫存區所說的S應該具有的哈希 ID 不同步。git status
要更新R 中的 Git 索引，您現在必須運行：
git add path/to/submodule
which records the hash ID that's actually checked out in S, in the index that the R Git is using for R. This is not yet committed: like anything in Git's index / staging-area, it's simply ready to go into the next commit you make. You can now update any other files in R as well if necessary, and git add those, and then run git commit to make a new commit with a new gitlink.
The new R commit will now call for the commit in S that you obtained when you ran git submodule update --remote from R to update your S from S's origin. Note that none of these have anything to do with R itself, and you don't have to pick out an S commit by doing git submodule update --remote. Since S is a repository, you can enter the submodule:
cd path/to/submodule
and you're now operating in a Git for S instead of a Git for R. You can now do everything you'd do in any ordinary repository, because you're in any ordinary repository. It's just that this ordinary repository is acting as a submodule too. So once you get S onto a commit you like—even if you have to make this commit—you can pop back over to repository R and git add path/to/submodule to get the new hash ID recorded.
Remember, though, that if and when you make a new commit in R and git push that commit to R's origin, someone else can grab the new commit from that (fourth) Git repository to their (fifth) Git repository that's a clone of R. There's no problem so far, but if they now check out your new commit, that commit you just made says that they should control their S clone by checking out the commit you made in your S clone. If you have not yet sent this commit to someplace that they can find it, they will now get an error if they run git submodule update in their R clone.
（到此為止，根據您使用的子模塊的數量，我們最多有 6 個或 8 個甚至 42 個克隆，這非常令人困惑。關鍵是要記住超級專案——上面符號中的R s——要求提交在他們的小號用原料哈希ID ubmodules，這意味著任何人誰克隆子模塊的需求，以獲得一個與哈希ID提交，這意味著你通常需要git push在子模塊，你之前git push在superprojects。由于所有我們曾經做任何存盤庫是添加新的提交，我們從來沒有運行git reset或者git push --force還是git rebase，對不對？ -這始終作業。好了，直到我們開始使用復位，底墊，并被迫推，或忘了限制。）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/363603.html