我在一个软件团队工作，该团队由4-5名开发人员组成，他们在一个TFS项目中工作。我们正在考虑将整个代码库迁移到GIT。代码库由大约50个visual studio（2013）解决方案组成，分为大约300个项目。在项目中引用另一个程序集的首选过程是将项目添加到解决方案中，依此类推。我想这被认为有点混乱，但它有它的好处：
1：鉴于源代码已更新为最新版本，项目将始终使用最新版本进行更新。
2：创建发布分支时，会存储源状态的完整图片，如果需要（何时），很容易重现发布。
在考虑迁移到GIT时，最简单的方法是简单地移动所有解决方案和项目，就像单个GIT仓库一样。这引出了我的第一个问题。
在一个GIT回购中，将50个左右的解决方案分成300个项目的集合难以使用吗？我害怕忽略每个开发人员每天所做的更改的概述。
另一种方法，我认为这是正确的方法，是远离共享项目制度，并将代码库划分为逻辑上划分的部分与他们自己的GIT回购。 （我猜这会给我们带来大约10-20个回购）。为解决此问题中的引用项目，我们正在考虑使用本地nuget-server。
这引出了我的第二个（也是最后一个）问题。 看看上面提到的津贴。这些功能仍然可以维护吗？我们可以“自动更新”工作分支中的nuget引用，但是将它们冻结到发布分支上的特定版本吗？
答案 0 :(得分：1)
我害怕忽略每个开发人员每天所做更改的概述。
不，您不会忽略该概述，并且可以轻松衡量一个协作者的贡献（例如，in this answer）
这些功能是否仍可维护？
是的：这些10-20个项目将在一个父级回购中重新统一，如 submodules 。
您可以轻松configure a submodule to follow a branch，就像其master分支一样
在＆＃34; Git submodules: Specify a branch/tag＆＃34;和git submodule上查看有关该配置的详情。
自动更新：
git submodule update --remote --init --recursive
冷冻：
cd /parent/repo
git add .
git commit -m "Freeze all submodules SHA1"
正如jessehouwing在评论中所提到的，Visual Studio 2013及其native Git support并未包含子模块。它是highly requested though Git命令行仍可用于使用子模块的更新/冻结步骤。