你可以直接在Git子模塊中開發嗎？

我有兩個項目（A & B）。他們都使用Common項目。我想通過子模塊將Common包含到A & B中，因爲那樣我可以直接將每個提交都綁定在A & B中，它們在Common中依賴於哪些提交。你可以直接在Git子模塊中開發嗎？

在過去，我試圖讓我的團隊使用這樣的子模塊，但我們無法讓它順利運行。我們正在從子模塊內部開發通用代碼&從子模塊提交，但我們遇到了很多問題，我們恢復到將所有項目都放在同一目錄下（C：\ dev \ A，C：\ dev \ Common）。

我很確定我們不知道應該如何使用子模塊，但是如果您不能直接在子模塊中開發通用代碼，是否不會使開發更加困難？有人可以解釋子模塊的正確使用嗎？

2011-02-15 kelloti

非常密切相關：[高度耦合的git子模塊]（http://stackoverflow.com/questions/3712917/highly-coupled-git-submodules）。我還沒有真正開始使用這個設置（它讓我感到害怕，因爲我的同事幾乎不知道如何合併），但是有一些鉤子可以幫助你。 – Cascabel 2011-02-15 18:58:55

@Jefromi - 呃！我知道你和同事來自哪裏。我有點猶豫是否繼續這樣做，除了我認爲它能夠在生產分支中修補常見代碼中的錯誤方面增加很多確定性。感謝您的鏈接！ – kelloti 2011-02-15 20:27:23

您可以直接從子模塊開發（如我在「true nature of submodules」中所解釋的）。
但是，每次您在子模塊中提交某些內容（並將其發佈到某處）時，都需要確保在父庫中提交。

現在你有兩個子模塊組織：

遞歸包括

 
A 
    Common 
    (Common could depend itself on other dependencies) 
B 
    Common 
    ...

或直接包括（僅直接依賴）

 
ParentA 
    A 
    Common 
    Other A dependencies 
ParentB 
    B 
    Common 
    Other B dependencies

（實際上，如果Common有它自己的依賴A或B將取決於「ParentCommon」，這將是指Common及其所有直接依賴）

除非你有一個結構勢在必行，其中Common絕是A的一個子目錄，我會推薦第二個組織，它更接近你的C:\dev\A,C:\dev\Common之一。

其實，我更喜歡只一個深度依賴，其中對於ParentA，我列出所有的依賴，直接和間接的，如子模塊。

這是因爲，與任何工具試圖管理的依賴關係，你仍然需要做出決定：

依賴性的衝突（A取決於X這就需要Z1，並且Y這需要Z2：哪個版本Z你想在你的項目中使用/編譯嗎？）
依賴倍率（當A取決於X這就需要Z1，而A也選擇使用X2）
依賴週期（其中A取決於B依賴於C它採用... A！）

來源

2011-02-15 17:57:41 VonC

`直接包含'使用子模塊嗎？ – kelloti 2011-02-15 18:15:42

子模塊不是特別順暢的工作，你打算在這裏的方式。正如你可能已經注意到，承諾在一個子模塊更改項目（如Git的V1.7，很可能永久），您需要：

使輔助模塊的變化。
提交到子模塊，獲取新的SHA散列。
用新散列更新外部項目的.gitmodules文件。
承諾外部項目。

如果您以鎖步形式開發子模塊和外部項目，這很麻煩。這是「正確的方法」，只要在混合代碼庫時寧願選擇穩定的軟件配置而不是簡單的配置，但是在這種情況下，命令序列在病態上很長。

當彈出爲什麼疊加，雖然與子模塊步調一致的發展可能表明的幾個大問題之一：

你沒有你的子組件之間的界面清晰，並實現細節跨邊界泄漏。
對於您的子組件，您沒有一個精心設計的界面，所以當您解決一個更有趣的問題時，您不得不重新創新。
您的界面穩定且質量很高，但是您對子模塊代碼沒有很好的QA過程，所以您不斷嘗試完成其他工作。（特別是如果A和B不斷變化不同的東西）你的「通用」代碼實際上比你想象的要小得多，或者應該以不同的方式進行分組。

這些案件都不是一定真實的你，但這些都是導致你遇到的可怕步調一致子模塊更新工作流程的問題之一。子模塊工作的很好，當你可以幾乎依賴共享庫和頭文件，但有一些令人信服的理由（例如奇怪的編譯標誌，必須一致）從源代碼編譯。我的方法是解決這些問題，如果它們是真正的根本原因。

如果這些問題不存在，然而，它可能是git是你的錯誤工具。這讓我很痛苦，但這絕對是一種可能性。

來源

2011-02-15 18:12:18

你可以直接在Git子模塊中開發嗎？

回答

相關問題