Intro to Version Control and Git
Non-Azure Repos and Pipelines
The course is part of this learning path
This course explores how to implement version control on Azure repos. It begins with an overview of what source control is and the different types of source control available. It then looks at the key elements of branching, different branching strategies, and how they impact the development process. You'll move on to learn about pull requests and merging as repository functions, and the different merging scenarios available to you. Finally, you'll be guided through using third-party systems in conjunction with Azure DevOps. This course contains several guided demonstrations from inside the Azure portal to give you real-world exposure to the concepts covered throughout the course.
If you have any feedback relating to this course, please feel free to reach out to us at email@example.com with any questions or comments.
- Understand what version control and Git-based repositories are
- Learn about branching and the branching strategies
- Learn about pull requests and merging in Azure DevOps
- Set permissions on repositories and on TVFC in Azure DevOps
- Use Azure DevOps in conjunction with build pipelines set up on other platforms
This is an intermediate level course suited to developers, engineers, and project managers.
To get the most out of this course, you should have a basic understanding of the software development lifecycle. Knowing what's involved in deploying software to a production environment would also be helpful. If you want to follow along with the demonstrations in this course, you'll need to have an Azure DevOps account.
What is Version Control? Version Control, as the name suggests, is a means to manage different versions of your source code, and is also commonly referred to as Source Control. These code versions might be explicit versions of the application, like 1.9 and 2.0, or might be work-in-progress versions, or customized versions for different customers. Managing multiple developers is another key component of Version Control, especially as software teams get bigger, become more numerous as applications become more complex, and those teams are geographically distributed. Implicit in Version Control is maintaining a record of changes to the source code, who made the change, when they made it, and a summary of what the change was. While not an explicit element of Version Control, online code repositories have become synonymous with it and serve as a backup vehicle for source code. As will become apparent, the tree analogy is often used when talking about Version Control. The main thread of the code development is called the trunk, often referred to as the master trunk, while deviations or splits from that are called branches. Because developers aren't arborists, the master trunk is often called the main branch. This technology isn't new and falls under two main types, centralized and distributed.
Centralized Version Control systems are modeled on client-server architecture, where developers check out files to work on, much like taking a book out from the library. While the file is checked out, it is locked within the Version Control system, preventing anyone else from making changes to it. This type of Version Control was very much in vogue at the beginning of the century and is represented by well known, if you are of a certain age, products, like CVS, Concurrent Versions Systems, Subversion, and Team Foundation Server, which morphed into Team Foundation Version Control, abbreviated to TFVC. One side-effect of the check-out/check-in model is behavioral. Developers tend to put off checking in until their body of work is totally complete as they don't want to break the build. This leads to large check-ins with associated conflict issues, and makes reverting or unwinding changes more difficult.
Moving forward, distributed systems are very much the flavor of the month now, and if we were to be completely honest when we talk about distributed systems, we are invariably talking about Git. Instead of checking out and locking files from the master trunk, a developer takes a copy, called a clone, typically of the whole code base, and has it locally, where they can work on any part of it. Obviously, this is a significant advantage over the check-out/check-in model when it comes to having multiple developers working on the same code base, especially with remote workers who don't have to be connected all the time. Changes in the form of branches are typically merged back to the master trunk with what's called pull requests, which I'll get into later.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.