What are Azure Repos? - Azure Tutorial

- [Instructor] Version control systems are vital for all software projects. Being able to capture frequent copies of every team member's source code while working is essential for project sanity. All modern version control systems support using a common repository location. A place on the server or in the cloud where the shared code base is available for every team member to access and update. In the Azure devOps world, this is supported to the Azure Repos feature. Simply put, this is a location where you can store your repos on the Microsoft cloud servers. Each project in a DevOps organization can have multiple repositories. DevOps creates a default repo when you create the project but you can add more if you like. When talking about what can be hosted in Azure DevOps, there are two choices. Git is the default provider, or you can choose Team Foundation Version Control, also known as TFVC. Both systems handle all the common repository actions. You can commit and check in code changes, manage files and folders in the projects. You can create new code branches and handle emergency conflicts too. Git has become the industry standard for version control. Git is a distributed system, which means each developer has a copy of the entire source repository on their dev machine. Developers can commit each set of changes to their local computer and perform version control operations, such as commit, view history, code DIFs and more without a network connection. A single developer can work with Git repos on their local computer. When it's time to collaborate with others or work on a software team, it is sensible to put a copy of the repository in a shared location. This is called a Git remote. Then team members can work locally. To sync with their team, they push their changes to the remote server when ready or they issue pull request to the server so that teammates can review before pulling the changes into the repository. It want surprise you to learn that Azure Repos is a hosting service for Git remotes. A natural question to consider is what about GitHub? It is part of the Microsoft ecosystem now and it also has a set of DevOps services including serving as a Git repository host. In fact, it seems to be the most popular Git hosting service available. When talking strictly about Git hosting, there is little difference actually between Azure DevOps and GitHub. Both are suitable hosting services for Git repositories. You can host on GitHub and use Azure DevOps for all the other services or keep everything in Azure DevOps. Some people consider Azure DevOps more suitable for enterprises and big projects. This is perhaps truest if you need to maintain your own Azure DevOps server and cannot use cloud services due to legal or other reasons. Now let's look at TFVC, which is the acronym for Team Foundation Version Control. It is a centralized client service system. It's been a staple of Microsoft tools for a long time. In a centralized system, the server is in control. It is the source of truth for the code in the repository. Typically team members check out the files needed for work. and check in changes back to the server. Historical data is maintained on the server only. Should you choose TFVC? Well, it seems to me that most new projects choose Git. But I've worked in many enterprise scenarios and know that companies keep using known technology for years after the initial adoption. So if your company has code basis in TFCC, you can start using Azure DevOps services yet keep the historic original repo intact. For this course I'm using Git. The examples shown in this chapter are simple. If you are new to Git our version control, you can find more comprehensive courses on our site. If you are an experienced Git user, there isn't much to learn. Azure DevOps is simply another place to work with Git remotes. The primary differences show up when you look at the additional tools on the DevOps portal. The way you use Git on the developer computer will not change. This is a rundown on how we'll use Git in the rest of the chapter. Someone on our team creates the repository on the web portal. Individual team members clone the repo to their local computer. A team member creates a branch for new work. One or more people can work on the branch. Team members commit changes to a branch. When the code is ready, a team member submits a pull request. The designated team members review the request and approve and merge the changes into the repo to somehow to manage code changes during development. Code repositories are more useful when available in a central accessible location. In recent times, we've learned that distributed systems like Git offer many advantages for team development. There are many hosting options available for Git remotes. If you want to use Microsoft hosting, look at Azure Repos or GitHub. Also if you're old school and want to choose a centralized client server as your repos, has that option too.