从TFS迁移到GIT，将项目共享到nuget [英] Migrating from TFS to GIT, Shared projects to nuget

问题描述

我正在一个软件团队中工作，该团队由在单个TFS项目中工作的4-5名开发人员组成。我们正在考虑将整个代码库移至GIT。该代码库由大约50个视觉工作室（2013）解决方案组成，分为大约300个项目。在项目中引用另一个程序集的首选过程是将项目添加到解决方案等。我想这被认为有点混乱，但它有它的特权：

1：鉴于源代码已更新到最新版本，项目将始终使用最新建成时。

2：创建发布分支时，会存储源状态的完整图片，并且如果（需要时）很容易就可以重新发布发布。 / p>

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

在一个GIT仓库中，将50个左右的解决方案分成300个项目会很难合作吗？我害怕放松每个开发人员每天进行的更改的概述。另外一种方法，我认为这是正确的方法，是离开共享项目制度，并将代码库分成逻辑分割的部分和自己的GIT仓库。 （我想这会让我们有大约10-20回购）。为了解决这个问题中的参考项目，我们正在考虑使用本地nuget-server。

这让我回到我的第二个（也是最后一个）问题。
看看上面提到的津贴。这些功能还可以保持吗？我们能否在工作分支中自动更新nuget引用，但是将它们冻结到发布分支上的特定版本？

blockquote>

我每天都会忽略每位开发人员所做的更改。

不，您不会忽略此概述，并且可以轻松衡量一位协作者的贡献（例如，在此答案中 a>）

这些功能仍可以保留吗？

是：这些10-20个项目将在一个父回购站内重新组合，如 submodules 。

您可以轻松配置一个子模块来跟随分支，就像它的 master 分支一样。

在 Git子模块：指定分支/标签和 git submodule 。

• auto-update：
  
  

    git submodule update --remote  - -init --recursive 
    




• freeze：
  
  

    cd / parent / repo 
   git add。 
   git commit -m冻结所有子模块SHA1
    

正如 jessehouwing 在评论中提到的，Visual Studio 2013及其原生Git支持不包含子模块。这是高度要求，但是。
Git命令行可用于使用子模块的更新/冻结步骤。

I am working in a software team that consists of 4-5 developers working in a single TFS project. We are considering moving the entire codebase to GIT. The codebase consists of about 50 visual studio (2013) solutions divided into about 300 projects. The preferred procedure of referencing another assembly in a project has been to add the project to the solution and so on. I guess this is considered a bit messy, but it has its perks:

1: Given that the source code is updated to latest, the projects will always be updated with the latest when built.

2: When a release branch is created, the complete picture of the sources state is stored, and it is easily possible to reproduce the release if (when) needed.

When considering migrating to GIT, the easiest way would be to simply move all the solutions and projects, pretty much as is to a single GIT repo. This leads me to my first question.

Will a collection of 50 or so solutions divided into 300 projects in a single GIT repo be hard to work with? I am afraid to loose overview of the changes performed by each developer on a daily basis.

Another approach, and I think this is the correct way, is to step away from the shared projects regime and divide the codebase into logically divided parts with their own GIT repos. (I would guess this would leave us with about 10-20 repos). To solve the referenced projects in this matter, we are considering using a local nuget-server.

This leads me to my second (and last) question. Take a look at the perks mentioned above. Can these features still be maintained? Can we "auto-update" the nuget references in the working branch, but freeze them to a specific version on a release branch?

解决方案

I am afraid to loose overview of the changes performed by each developer on a daily basis.

No, you won't loose that overview, and can easily measure the contribution of one collaborator (like, for instance, in this answer)

Can these features still be maintained?

Yes: those 10-20 projects would be reunited within one parent repo, as submodules.
And you can easily configure a submodule to follow a branch, like its master branch.
See more on that config at "Git submodules: Specify a branch/tag", and git submodule.

• auto-update:

  git submodule update --remote --init --recursive
  

• freeze:

  cd /parent/repo
  git add .
  git commit -m "Freeze all submodules SHA1"
  

As mentioned by jessehouwing in the comments, Visual Studio 2013 and its native Git support doesn't include yet submodules. It is highly requested though.
The Git command-line remains available for those update/freeze steps using submodules.

这篇关于从TFS迁移到GIT，将项目共享到nuget的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！