Everything Starts with Source Control

Source control is one of the most basic tools that is used in software development. Therefore, it is probably safe to assume that you have worked with source control before. For that reason, this chapter will contain only a brief introduction to source control and quickly move on to more advanced topics to help you to set up your source control to support DevOps practices.

Multiple DevOps practices rely on source control, hence, setting up your repositories to continuously deliver value to your users is a great way to get started and a prerequisite for many of the subjects in the following chapters.

The following topics will be covered in this chapter:

• The types of source control in Azure DevOps
• Source control systems
• Selecting a branching and merging strategy
• Securing source control using branch policies
• Other tools that are available for...

Technical requirements

To practice the subjects covered in this chapter, you may need an Azure DevOps organization.

Types of source control in Azure DevOps

While there are many different source control systems in existence, they can be classified into two categories, centralized and decentralized source control, as follows:

• In a centralized source control system, only the server has the full history and the full set of branches that make up the repository.
• In decentralized source control, everyone working with the repository has a full copy of the repository, all of the branches, and its history.

Azure Repos, part of Azure DevOps services, offers both types of source control through TFVC and Git. The next two sections discuss both types of source control in more detail.

Centralized source control

In a centralized source control system...

Source control systems

There are many source control systems in use, but in this chapter, we will only be looking at the three currently most used. They are the following:

• Team Foundation Version Control (TFVC)
• Git
• Subversion

Within Azure DevOps, only TVFC and Git are available. Subversion is a centralized source control system that is created by the Apache Foundation. In the upcoming subsections, we'll take a look at TFVC and Git in more detail and learn how to migrate sources between them. Subversion is discussed at the end of this chapter in the Other tools for source control section.

Team Foundation Version Control

Team Foundation Version Control (TFVC) is a centralized source control system that was introduced...

Selecting a branching and merging strategy

Source control allows you to keep a history of all of the changes you have made to your files but also allows working separately from your team members for a while if you so desire. We call this branching. When you are branching in source control, you fork the line of changes currently registered. We call such a fork a branch. A branch allows you to temporarily isolate some work from the rest. If you at any point want to integrate the changes from a branch with the changes on the other fork, you can merge these changes back. Branches are often used for working on not yet complete features, proofs of concept, or hotfixes. Using branches allows you to later decide which changes to include in the next version and which not to.

Branching strategies...

Managing repositories

When working in Azure Repos, every team project can have a maximum of one TFVC repository. However, when working with Git, you can have multiple repositories in the same team project. A discussion that is gaining more attention lately is that of having a single repository for all applications or a repository per application. Other topics that are important when managing repositories are creating and removing repositories, securing them, and setting policies on them.

Monorepo or multi-repo

You are using a monolithic repository (monorepo) when you are storing all of the code of all of your projects and applications in one single source control repository. Opposed to this, you might be using multiple repositories...

Other tools for source control

Next to the source control systems available in Azure Repos, there are also some other well-known systems that you should know about:

• GitHub
• GitLab
• Subversion

We'll go over each of these in the upcoming subsections.

GitHub

GitHub is a hosted source control provider that delivers hosted Git repositories. GitHub allows anyone to create as many publicly visible repositories as they want. Only, when you create private repositories that require three or more contributors, you must switch to a paid subscription.

This model that allows unlimited, free usage of the platform if developing in public has made GitHub, by far, the largest host of open source software in the world.

GitHub was acquired...

Summary

In this chapter, you have learned about source control. We saw that there are two types of source control: centralized and decentralized, both supported by Azure DevOps. TFVC is no longer recommended for new projects. You should use Git whenever starting a new project.

When using Git, you can have more than one repository in your team project. Per repository, you can assign policies to lock down specific branches and enforce the four-eyes principle. You have also learned about access control and how to provide users access to one or more repositories. Finally, you have learned about alternative tools and how to migrate sources from one tool to the other.

You can use what you have learned to make decisions on which type of source control system to use in your products. You can now professionally organize the repository or repositories you work in. You are now able to work...

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. What are the differences between centralized and decentralized source control and which work best in what situation?
   
2. True or false: Git is an example of decentralized source control.
3. Which of the following is not a common branching strategy?
   
   1. Release Flow
   2. Rebasing
   3. GitFlow
   4. GitHub flow

3. Many companies want a code review to be performed before code is merged into the master branch. What construct is used to do so when working with Git and how can this be enforced in Azure DevOps?
4. Which of the following are not valid merge strategies?
   
   1. Rebasing
   2. Trunk-based development
   3. Merge commit
   4. Squash commit

Further reading

• More information about working with Git can be found at https://docs.microsoft.com/en-us/learn/paths/intro-to-vc-git/.
• The original Microsoft advice on TFVC versus Git can be found at https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops&viewFallbackFrom=vsts.
• More information about Git LFS can be found at https://docs.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops.
• Instructions for downloading Git LFS can be found at https://git-lfs.github.com/.
• More information about migrating to Git can be found at https://docs.microsoft.com/en-us/azure/devops/repos/git/import-from-TFVC?view=azure-devops.

• An Atlassian tool for converting an SVN repository to a local Git repository can be found at https://www.atlassian.com/git/tutorials/migrating-convert.
• More information about GitFlow can be found...