我的5個開發團隊維護一箇中等規模的應用程序，由6個解決方案組成（又名部分）。目前，我們使用TFS進行源代碼管理。每個解決方案都位於其主分支中。一個大的Git回購或多個小的回購
我想遷移到Git。我的問題是是否對所有6種解決方案都有1個Git回購，或者對每種解決方案使用單獨的Git回購。
吸引我有一個單一的Git回購，這是因爲：
另一方面，一個單一的Git倉庫就意味着對任何解決方案的更改都會導致我們的TeamCity CI服務器上的所有解決方案全面重新生成。
尋找來自其他團隊負責人在這個問題上的一些見解。
即使在使用git時，它目前承認按項目使用1個回購（並且大部分答案或建議都會告訴你這樣做），但它們確實是將所有內容放入同一個存儲庫的解決方案，稱爲'monorepo'戰略。 （谷歌，Facebook和微軟）正在（幾乎）走向它......所以你可以很容易找到一些關於正反兩面的文檔。
例：https://github.com/babel/babel/blob/4c371132ae7321f6d08567eab54a59049e07f246/doc/design/monorepo.md
一旦你瞭解的主要問題之一是版本控制工具的性能（但混帳肯定可以支持5開發團隊），它更像是一個項目的感覺......因爲它似乎你似乎已經看到了一些優勢，我強烈建議你測試它！
此外，如果您不滿意，則用於拆分存儲庫（保留歷史記錄）的git命令比合並存儲庫容易得多，因此似乎首先嚐試。
在我的團隊中，我們越來越趨向monorepo。
我的5個開發團隊維護一個由6個解決方案（又名部分）組成的中型應用程序。
如果這是一個應用程序，monorepo確實可能是最好的解決方案。
但是，如果您在使用nuget管理的解決方案之間存在依賴關係，則必須解決該問題。
要麼你刪除的NuGet使用，並且使用二進制依賴（沒有辦理入住手續的他們！），所以你必須建立所有（但如果你想用樹枝將是困難的）。
要麼你接受，使2個提交做一個更新（如你有多個Git倉庫做）。可以手動完成或通過構建自動完成。
PS：git的子模塊是困難的，不是很勸了git的用戶第一次......所以基於這樣一個解決方案將是:-(
疼痛。另一方面，一個單一的Git回購意味着更改任何方案導致一個新的完整的重建我們的TeamCity CI服務器上的所有解決方案。
不一定，你可以做出不同的構建爲每個解決方案，並設置每個TeamCity的觸發僅在自己的解決方案文件夾。
Ps2：我做了一個更長的回答，期待;-)我希望這會有所幫助...
保持現有方法，每個解決方案只有一個回購。如果需要，可以將TeamCity配置爲僅基於特定回購中的更改進行構建。我知道詹金斯可以做到這一點。
我會保持每個項目在自己的回購，並讓建設服務器與他們分別進行交互。您仍然可以簡化開發人員的工作，並通過創建一個包含每個項目回購作爲子模塊的單個回購協議來促進跨回購的變更協調。因此，開發人員檢查大回購（通過子模塊引用，將獲得項目回購），而構建服務器只需要取回項目回購。
對於開放源代碼，您想在其中公開VCS對整個世界的訪問，那麼您應該爲每個項目存儲一個存儲庫。
對於內部工作單個存儲庫（或幾個大倉庫）是遠遠優於。如果要確保需要交互或共享資源的代碼庫之間的一致性，那麼很難做到。在現實世界中，在任何有許多存儲庫的情況下，我發現自己在額外開銷和syncronisation問題上遇到問題，這些問題需要通過不必要的方式跨越其他存儲庫。
有警告。對於彼此無關的事情，他們可以愉快地在單獨的存儲庫中。 Git在mono-repos中也存在一些缺陷。你會看到這個，如果你把它與SVN中的monorepo工作得很好（外部，不需要拉整個回購，可以得到一個特定的文件夾等）。你可以通過使用符號鏈接來解決其中的一些問題。
如果你的團隊沒有很多的經驗與子模塊，然後我會建議對這一做法。子模塊在紙上很酷，但實際上它們確實會造成混亂。 – zypherman
「如果你沒有經驗與他們，不要獲得與他們的經驗」？如果你對他們有一個具體的問題，我會很有興趣知道這件事，但是這聽起來像是一種FUD的人，如果他們沒有 - 也不想 - 學習如何正確使用一個功能。 –