Introduction

The post provides an example of how feature branching can be used to allow a developer apply their work item changes to a repository main branch. The example will discuss:

• Creating a user story (work item) branch based off the main branch
• Implementing the changes within that branch
• Raising a pull request of the changes, which, after being approved, are merged into the main branch

The tools used in this example are

• Azure DevOps
• Azure Repos Git
• Visual Studio 2022

Example

1.) Clone the repository

The ‘products-contoso’ repository is cloned to the developer’s local environment. The local develop branch (i.e. the main branch in this example) can be viewed by navigating to ‘Git’ on the menu bar, then ‘Manage Branches’ (Figure 2). The contents of the branch can be viewed on the local file system (Figure 3)

2.) Create a temporary local user story branch

Since it was just cloned, the local develop branch already contains the latest changes. Thus, a new user story branch ‘story/48286’ can be immediately created off the develop branch, without requiring a fetch/pull

3.) Implement the required changes in the user story branch

The changes e.g. updating the NonComplianceForm.ts file (Figure 5) are stored in the file system (Figure 3).

(Note: if the developer was to now try and checkout another branch, the changes in the file system could potentially be lost. So, the following options are presented to the developer (Figure 6).)

4.) Commit changes in the user story branch

These changes to the NonComplianceForm.ts file are committed locally and displayed in ‘Outgoing’ (Figure 7)

5.) Push changes in the user story branch

Pushing the commit (Figure 7) results in the user story branch ‘story/48286’ being created in the Azure DevOps repository ‘products-contoso’ (Figure 8)

6.) Create pull request

The changes in user story branch ‘story/48286’ are now ready to be placed in a pull request. Once the pull request is complete, the user story branch is merged into the develop branch within Azure DevOps

7.) Further changes

Consider the situation where, in a few days time, another change needs to be made to the user story. The developer could make the changes in the existing user story branch. However, there could be merge issues when the user story branch is updated with the latest changes from the develop branch. If this is the case, it could easier to abort the merge and create a new user story branch containing the latest changes.

References

Linking Work Items to Git Branches, Commits, and Pull Requests

https://learn.microsoft.com/en-us/azure/devops/boards/work-items/about-work-items?view=azure-devops&tabs=agile-process

https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops