How to do it...

1. After you've cloned the master branch into a local repository, create a new feature branch, myFeature-1:

myWebApp> git checkout -b feature/myFeature-1
Switched to a new branch 'feature/myFeature-1'

1. Run the Git branch command to see all the branches. The branch showing up with an asterisk is the currently-checked-out branch:

myWebApp> git branch
* feature/myFeature-1
  master

1. Make a change to the Program.cs file in the feature/myFeature-1 branch:

myWebApp> notepad Program.cs

1. Stage your changes and commit locally, then publish your branch to the remote server:

myWebApp> git status 

On branch feature/myFeature-1
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
 modified: Program.cs

myWebApp> git add .

myWebApp> git commit -m "Feature 1 added to Program.cs"

[feature/myFeature-1 70f67b2] feature 1 added to program.cs
 1 file changed, 1 insertion(+) 

myWebApp> git push -u origin feature/myFeature-1

Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Analyzing objects... (3/3) (10 ms)
remote: Storing packfile... done (44 ms)
remote: Storing index... done (62 ms)
To http://Azure DevOps Server2018/Azure DevOps Server/DefaultCollection/PartsUnlimited/_git/MyWebApp
 * [new branch] feature/myFeature-1 -> feature/myFeature-1
Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

The remote shows the history of the changes:

1. Create a new pull request (using the VSTS CLI) to review the changes in the feature-1 branch:

> vsts code pr create --title "Review Feature-1 before merging to master" --work-items 38 39 `
            -d "#Merge feature-1 to master" `
            -s feature/myFeature-1 -t master -r myWebApp -p $prj -i $i

The team jointly reviews the code changes and approves the pull request:

The master is ready to release, team tags master branch with the release number:

1. Start work on Feature 2. Create a branch on remote from the master branch and do the checkout locally:

myWebApp> git push origin origin:refs/heads/feature/myFeature-2 

Total 0 (delta 0), reused 0 (delta 0)
To http://azsu-p-Azure DevOps Server2018/Azure DevOps Server/DefaultCollection/PartsUnlimited/_git/MyWebApp
 * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2

myWebApp> git checkout feature/myFeature-2

Switched to a new branch 'feature/myFeature-2'
Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

1. Modify Program.cs by changing the same line of code that was changed in feature-1:

1. Commit the changes locally, push them to the remote repository, and then raise a pull request to merge the changes from feature/myFeature-2 to the master branch: 

> vsts code pr create --title "Review Feature-2 before merging to master" --work-items 40 42 `
            -d "#Merge feature-2 to master" `
            -s feature/myFeature-2 -t master -r myWebApp -p $prj -i $i

With the pull request in flight, a critical bug is reported in production against the feature-1 release. In order to investigate the issue, you need to debug against the version of code that's currently being deployed in production. To investigate this issue, create a new fof branch using the release_feature1 tag:

myWebApp> git checkout -b fof/bug-1 release_feature1

Switched to a new branch 'fof/bug-1'

1. Modify Program.cs by changing the same line of code that was changed in the feature-1 release:

1. Stage and commit the changes locally, then push changes to the remote repository:

myWebApp> git add .
myWebApp> git commit -m "Adding FOF changes"
myWebApp> git push -u origin fof/bug-1 

To http://azsu-p-Azure DevOps Server2018/Azure DevOps Server/DefaultCollection/PartsUnlimited/_git/MyWebApp
 * [new branch] fof/bug-1 -> fof/bug-1
Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin. 

1. Immediately after the changes have been rolled out to production, tag the fof\bug-1 branch with the release_bug-1 tag, then raise a pull request to merge the changes from fof/bug-1 back into the master:

> vsts code pr create --title "Review Bug-1 before merging to master" --work-items 100 `
            -d "#Merge Bug-1 to master" `
            -s fof/Bug-1 -t master -r myWebApp -p $prj -i $i

As part of the pull request, the branch is deleted; however, you can still reference the full history to that point using the tag:

With the critical bug fix out of the way, let's go back to the review of the feature-2 pull request. The Branches page makes it clear that the feature/myFeature-2 branch is one change ahead of the master and two changes behind the master:

If you tried to approve the pull request, you'll see an error message informing you of a merge conflict:

1. The Git Pull Request Merge Conflict resolution extension makes it possible to resolve merge conflicts right in the browser. Navigate to the Conflicts tab and click on Program.cs to resolve the merge conflicts:

The user interface gives you the option to take the source version, target version, or add custom changes and review and submit the merge. With the changes merged, the pull request is completed.