从TFS迁移到GIT,将共享项目迁移到nuget

时间:2013-12-31 11:41:26

标签: git version-control tfs nuget visual-studio-2013

我在一个软件团队工作,该团队由4-5名开发人员组成,他们在一个TFS项目中工作。我们正在考虑将整个代码库迁移到GIT。代码库由大约50个visual studio(2013)解决方案组成,分为大约300个项目。在项目中引用另一个程序集的首选过程是将项目添加到解决方案中,依此类推。我想这被认为有点混乱,但它有它的好处:

1:鉴于源代码已更新为最新版本,项目将始终使用最新版本进行更新。

2:创建发布分支时,会存储源状态的完整图片,如果需要(何时),很容易重现发布。

在考虑迁移到GIT时,最简单的方法是简单地移动所有解决方案和项目,就像单个GIT仓库一样。这引出了我的第一个问题。

在一个GIT回购中,将50个左右的解决方案分成300个项目的集合难以使用吗?我害怕忽略每个开发人员每天所做的更改的概述。

另一种方法,我认为这是正确的方法,是远离共享项目制度,并将代码库划分为逻辑上划分的部分与他们自己的GIT回购。 (我猜这会给我们带来大约10-20个回购)。为解决此问题中的引用项目,我们正在考虑使用本地nuget-server。

这引出了我的第二个(也是最后一个)问题。 看看上面提到的津贴。这些功能仍然可以维护吗?我们可以“自动更新”工作分支中的nuget引用,但是将它们冻结到发布分支上的特定版本吗?

1 个答案:

答案 0 :(得分:1)

  

我害怕忽略每个开发人员每天所做更改的概述。

不,您不会忽略该概述,并且可以轻松衡量一个协作者的贡献(例如,in this answer

  

这些功能是否仍可维护?

是的:这些10-20个项目将在一个父级回购中重新统一,如 submodules 。 您可以轻松configure a submodule to follow a branch,就像其master分支一样 在" Git submodules: Specify a branch/tag"和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命令行仍可用于使用子模块的更新/冻结步骤。