Git子模塊亂七八糟：如何與不熟悉git的開發人員一起使用git子模塊？

Question

我對使用git的子模塊功能感到非常沮喪。 要么我仍然沒有做對，要么就是因為我沒想到這一點。 以下項目情況給出：

Project
  | .git
  | projsrc
  | source (submodule)
  | proj.sln

在此方案中， 源指向包含所有項目中的公共源數據的另一個存儲庫。 在源代碼下發生了很多開發，也在projsrc下。 遺憾的是， Project指向源子模塊的一些提交，而不是它的實際HEAD。 這是通常的git行為，據我所知。

我已經發現了

git submodule update

只需獲取與主項目一起提交的子模塊版本。 但是，我真的希望始終與子模塊開發保持同步，但是沒有任何真正的線索如何做到這一點。 因此我的問題是：

是否可以將項目附加到子模塊的HEAD，不管這是否會破壞項目的編譯。 我只是不想總是進入子模塊目錄並執行git pull 。 因為我認為我可以放棄在子模塊目錄中完成的更改，因為這很簡單地附加到提交而不是真正的任何分支左右。

請考慮以下限制 ：

• 我們小組的開發人員並不熟悉所有VCS。 我們之前習慣使用非常龐大的svn存儲庫，根本沒有任何外部repo功能。
• 我們正在開發Windows
• click'n'forget解決方案是最好的，因為大多數項目成員都使用命令行界面而感到害怕:)

Answer 1

子模塊指向特定修訂的原因很重要。 如果您指向HEAD，則構建將不可再現 。 也就是說，如果您查看昨天的項目版本，您將永遠不會知道昨天源@HEAD的確切版本。

這就是為什么它總是存儲特定的修訂版sha。

要拉動所有子模塊，您可以使用Easy way pull最新的所有子模塊

Answer 2

我不擅長Git和submodule。 但我認為一些簡單的規則會非常有用。

1. 從子目錄提交和推送。
2. 返回項目的根目錄，檢查狀態是否需要提交並再次推送。

當拉。 可以嘗試使用腳本將“pull / submodule update”捆綁在一起。 並且只在項目的根部進行。

Answer 3

考慮一下：

1. source指向HEAD（正如您所希望的那樣）。
2. 你對項目中的源進行了更改（你提交但不推送它們）
3. 現在你有兩個HEAD：一個在Project的源代碼中，另一個在你的公共源代碼中。

進行子模塊更新時，您希望在項目中出現哪一個？

在您的情況下，git的問題（和主要特性）是您將提交和推送視為原子操作。 事實並非如此。 Git是分散的。 沒有共同的HEAD。 您可能有多個具有不同HEAD的存儲庫。

考慮一下：

1. 你有3個開發人員（A，B和C）和一個git項目。
2. 他們都拉了一個項目的HEAD。
3. 每個開發人員都對項目進行了更改
4. 現在每個人都有3個HEADS：HEAD，B HEAD和C HEAD。

哪個HEAD你認為“真正的”HEAD？

那么，回答你的問題：如果你想讓公共源子模塊始終與中央存儲庫同步，那么git不是你的選擇。 也許沒有一個VCS可以幫助你。

您應該將git子模塊視為第三方庫，應該使用以下兩個步驟手動更新：

1. 拉你的子模塊（“下載第三方庫”）
2. 使用更新的子模塊提交項目（“將新版本的第三方庫放入項目中”）

如果要對子模塊進行更改，則應按相反順序執行相同操作：

1. 提交您的子模塊（“對第三方庫進行更改”）
2. 推送您的子模塊（“將您的更改發送給第三方庫維護者”）
3. 使用更新的子模塊提交項目（“將新版本的第三方庫放入項目中”）