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 firstname.lastname@example.org 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.
Okay, now on to the strategies. As you may have guessed, these strategies have more in common than their differences, but while differences are subtle, they are important especially when it comes to how your organization manages code flow and the development process.
GitHub Flow is the archetypal branching strategy, and pretty much what I described in the Got commitment, or should be committed slide. In GitHub flow, the master branch is always deployable and should reflect what is in production. Any new work is created in a branch off master. Regularly commit to that branch locally and push to that branch on the server. When the branch is ready or finished, open a pull request for the code to be reviewed. This can also be done when you need help, feedback, or a second opinion on the code. Once the branch has been reviewed and tested, it can be deployed into production. If the deployed branch causes issues or has bugs, it can be rolled back by deploying the existing master. Otherwise, the branch can be merged with master.
Next, we have Gitflow, which has, for all intents and purposes, two main branches. The master branch is stable code that reflects what is deployed in production. The development branch is the parent branch of most code changes. When a change is required, a branch is created from the development branch. These branches can be categorized as feature branches, branched from development merged to development, release branches, branched from development merged to master and development, and hotfix branches, branched from master merged to master and development. A development branch becomes like a master branch for a set of features. When a feature is finished, it is merged back to the development branch. To deploy the new functionality, a release branch is created from the development branch. The release branch, typically named as the release version number, including any bug fixes and tweaks, is merged back into development and master branches after the release is deployed. If a critical bug is discovered in the live application that can't wait for the next release, a hotfix is required. A hotfix is branched off master and merged back into master as well as development, so both code threads get the fix.
Forking, or fork and pull. This strategy is typically found in public projects where you want to use an existing code base as the starting point for your project. A developer will clone the original repository to their own remote repository, creating a new origin master branch. When forking a project, it is implied that you won't be trying to merge your changes back to the original.
Now for something completely different. Well, maybe not completely, but significantly. Release flow is Azure DevOps' internal take on Trunk Based Development, and where the line between branching strategies and code flow blurs. As the name implies, all branches, be they features, bugs or hotfixes, are branched directly off the master trunk. Where Release Flow diverges from traditional trunk-based models is how and when the code is deployed. This strategy puts emphasis on the release schedule, which is tied to deploying at the end of each sprint. The strategy is designed around workflow, adhering to continuous integration and deployment processes, and projects at scale. In terms of workflow, it fits with the sprint schedule, but the main reason to do this, as the sprints usually don't correspond to any one feature branch, is the time taken to do the actual deployment. There are literally hundreds of developers working on hundreds of branches at any one time. It is totally impractical to have deployments dictated by feature branch completion, as developers would spend too much time waiting for their queued release to be deployed before continuing with the next feature.
The first issue that comes to mind when looking at this graphic is how does it deal with half-completed features at the time of release deployment? Well, they use feature flags to turn off incomplete functionality within the code. If you are unfamiliar with feature flags, in its most elementary form, it is conditional branching around some code. That is, if the feature is enabled, show it, else don't. It can be a lot more sophisticated in terms of conditions to be evaluated, but that's it in a nutshell. The other issue is hotfixes. These are done on the main branch and then cherry-picked into the release branch.
The release flow strategy follows some strict conventions due to scale and working directly off the master trunk. Branch naming follows the convention of user name, then branch type, followed by description, although this has more to do with the number of developers. The development or topic branches need to be as small as possible, so work is broken down into its smallest logical functional units. This serves two purposes. It makes reviewing and testing much easier and quicker, while limiting damage if something does go wrong. And it's no surprise that testing is very important when merging straight back to the master trunk. Each feature branch is tested as if it was going into production before merging back to master, because in essence, it is.
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.