Setting Up Multiple GIT Repositories for Multiple Projects in VSTS

Question

I'm new to vsts and git. So I may be missing something obvious or not understanding how vsts will work.

Our team will be using a centralized workflow. Is there a place in VSTS to set up a place to house all of the repositries?

If I have over 50 repos and some of them are used on many projects. For example a web service project that provides common data to a bunch of different apps (website, internal support apps, mobile etc.)

If a project is created in vsts and that webservice and the moible app needs to be changed, it seems like the only option is to import the git repo directly into that project. When the project ends where does the repo go? Is there a way to set up a central place to house all the repos in VSTS? If so what is the work flow for using that repo (and others) in my new project?

Update

I know that git is distributed, however we still have a need to a repo that represents the most up to date repo. In the git book this is called the 'central' or 'blessed' repository.

Since VSTS creates a separate repo for every project. I am wondering how to manage this work flow from VSTS or is this something that is going to be a manual process.

I assume this is a common set up. Enterprise sized company with 50 - 100 code repos. Many projects that can touch many of the repos. I want to manage as much as I can from VSTS.

Answer 1

Software projects versus team projects

To build and deploy a software application, you begin by defining a software project. Software projects differ from team projects.

A team project defines a process and data storage in which you manage your software projects from planning to deployment. When you connect to VSTS or an on-premises TFS, you connect to an account or team project collection. Within that collection, one or more team projects may be defined. At a minimum, at least one team project must be created in order to use the system.

ref https://docs.microsoft.com/en-us/vsts/user-guide/concepts?view=vsts

One you have created your team project, you can have multiple git repositories in a team project.

To create a git repository:

After creating your multiple repositories, you can access them from

How many software projects you put into a specific repository is up to you. You could have a repository for API and another repository for APP. Or have only one to have the two.

Answer 2

For Git, it's a kind of Distribute Version Control Systems (DVCS) instead of Centralized Version Control Systems (CVCS). And DVCS has much advantages than CVCS. More details, you can also refer About Version Control in the git book.

And For your situation, the main problem seems to be how to share a git repo accross multiple projects (that means, a git repo may be used for other git repos which are located in different projects).

The common way to handle this situation is using git modules or git subtree. Assume the git repo webrepo in project1 also need to be used in repo2 (in project2) and repo3 (in project3). Then you can use any of below options to add webrepo to repo2 and repo3.

Option 1: Use git submodules

• Add webrepo as submodule for repo2 and repo3 separately:

    git submodule add <URL for webrepo>
  

• Get the updates to the submodule of repo2 and repo3 when webrepo updates:

    git submodule update --remote
  

• To push changes to webrepo from submodule, you can go to the path of the submodule, and then commit and push.

You can also refer the in git book Submodules.

Option 2: Use git subtree

• To add files of a branch from webrepo to repo2 and repo3, use the command:

    git subtree add --prefix=webrepo <URL for webrepo>
  

• To get changes from wenrepo to subtree:

    git subtree pull --prefix=webrepo <URL for webrepo>
  

• To push changes from subtree to webrepo:

    git subtree push --prefix=webrepo <URL for webrepo>
  

You can also refer the document Git subtree: the alternative to Git submodule.

Answer 3

We have labored over this decision and think that while submodules / subtrees can technically give you the traditional looking Visual Studio Solution with multiple projects loaded (and thus: source code that can be F10 or F11 stepped through across project boundaries), we're not feeling our team will ever be "Git"-ninja enough to manage this

We have mostly settled on learning how to take individual projects, and use a build pipeline to "Nuget-ize" them. Then, bring the "project reference" into other projects via NuGet. There is a concept supported by Azure DevOps / NuGet of a symbol server / NuGet Symbols package that can be published simultaneous with your NuGet which is supposed to ease the issue of the debugging challenges. I'm still too new to this to comment on it with any further opinion