Improving Azure DevOps cherry-picking
One of the more powerful git commands is the cherry-pick command. This command takes one or more existing commits and applies each commit’s changes as a new commit on a different branch. This can be an extremely powerful component of many git workflows such as the Azure DevOps team’s Release Flow. To highlight a common use-case for it, let’s talk about hot-fixing release branches.
In this scenario, we have a master branch that devs contribute to. When a release is ready, a release branch is created based off the latest commit in master and a deployment goes out to end users. After people begin using this newly released version, your team starts to get flooded with new bug reports—now it’s time for a hotfix!
As the dev tasked with fixing the bug, you create a hotfix branch (based off the head of the release branch) and commit the necessary changes (commits A and B in Figure 1) to that branch. After you’re satisfied that you have addressed the issue, you then open a pull request (PR) back into the release branch. The next step is to ensure that the next release doesn’t contain the bug—this is exactly when cherry-picking can help. So, you cherry-pick the hotfix commit(s) to a branch based off the head of master and open a PR into master.
Figure 1. Cherry-pick release workflow
Current Azure Repos cherry-pick support
This workflow is so common that Azure DevOps has a built-in capability to cherry-pick a PR’s commits to a new topic branch directly from a browser. However, this can be cumbersome if you need to apply commits to multiple branches at once while also opening new PRs.
For example, inside Microsoft, it is very common for product teams to cherry-pick changes into multiple branches at the same time. For example, the Office team has multiple versions at various stages of deployment at any given time, meaning there are multiple release branches to hotfix.
With the current mechanism, you would have to cherry-pick to each new topic branch and then open a PR from the topic branch into the target branch — for every branch that needed the hotfix. Therefore, we built this extension to help Microsoft product teams, such as Office, and we wanted to share it with everyone!
In order to provide an easy way to cherry-pick a PR’s commits to multiple branches at once, we added a new context menu item that sits right below the current cherry-pick menu item.
Figure 2. Multi cherry-pick extension context menu button
For each branch selected, a new topic branch will be created with the applied changes. If the Pull request option is selected, a pull request will be opened to the target branch.
Figure 3. Multi cherry-pick extension user interface
- Install the extension from the marketplace into your Azure DevOps organization.
- Navigate to your pull request.
- Select the context menu (…)
- Select Multi-cherry-pick.
- Add as many cherry-pick targets as you would like.
- After you click Complete, a summary page will appear with links to branches and PRs created from the tool.
This makes it much simpler to support workflows where multiple (or even just one) destinations need to have commits applied.
Note: because this extension is open source, you can file feature requests, suggestions, and issues at GitHub.
Lastly, please leave us a review in the marketplace; we’d absolutely love to hear your feedback.
Eu não tinha entendido o funcionamento do cherry-pick até este momento. Obrigado pelo exemplo de caso.
Nice article Begonã Guereca. I had big doubt about cherry-pick: if hotfix was based in the head off latest release branch or master.
Hi Begonã , I have a question. When we are syching the master branch with hotfixes made in a Hotfix- branch through cherry-picks, then if the branch (topic-branch) based-off master branch has the new changes in the code file in which we made hotfix changes in hotfix branch, so don’t you see that cherry-picks commits will replace the New changes of file present in the Topic branch?? i think cherry-pick will simply replace the version in topic branch causing the changes lost in topic branch. Would you explain it?
You show vertically-aligned commits in your chart. I’m wondering if they should be moved to mark chronological difference.