1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Implementing Version Control on Azure Repos

Pull Requests and Merging

The course is part of this learning path

AZ-400 Exam Prep: Microsoft Azure DevOps Solutions
course-steps
18
certification
1
lab-steps
5
description
1
play-arrow
Start course
Overview
DifficultyIntermediate
Duration38m
Students304
Ratings
4.7/5
starstarstarstarstar-half

Description

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 support@cloudacademy.com with any questions or comments.

Learning Objectives

  • 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

Intended Audience

This is an intermediate level course suited to developers, engineers, and project managers.

Prerequisites

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.

Transcript

You can't talk about version control and branching without talking about pull requests and merging. This is where the branching rubber meets the road and Azure DevOps supports several merging strategies; basic merge, squash merge, rebase and fast-forward, and rebase with merge commit.

Your basic merge command is for integrating changes from one branch to another, and by default, Azure DevOps uses the git merge command with the no fast-forward option. No fast-forward creates a commit on the target branch of the merge, let's say the main branch when merging a feature branch, and that commit contains the history of commits up to that point, so very helpful in terms of seeing how the development evolved. In contrast, a fast-forward merge is only possible when there is no divergence between the branches. This means there is nothing in the main branch code that isn't in the feature branch.

A squash merge takes the commits of the branch in question, say a feature branch with three commits, and condenses or squashes the contents of those commits into one commit on the target branch of the merge. In general, commit messages should clearly define the intent of the change and make sense when viewed in isolation, but too often, this isn't the case. The squash merge commit is a way to summarize the intent and function of a branch without all of its commit baggage. As the branch being merged is essentially discarded, the commit history is linear.

Rebasing is taking your branch and repositioning it at the end of its parent branch. Doing this effectively eliminates any divergence between the two branches, so a fast-forward merge can be performed to make the tip of the child branch now the tip of the parent, that is the child becomes an extension of the parent including its commit history. Like squash merge, this keeps the commit history linear, but also preserves individual commits.

Finally, we have rebase with a no fast-forward merge commit. The pull request commits are rebased to the end of the parent branch, then a no fast-forward merge is performed. Fundamentally, this is the same as the rebase with fast-forward merge, except branching and merging are immediately obvious when viewing the development history.

About the Author
Students7306
Courses11

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.