Git Branching In Visual Studio 2015

There are many different ways to use Git or Git workflows, you can even use it like a central repository similar to the way you would use SVN or Team Foundation Version Control but most of the popular and widely used workflows involve branching.

In this post I am going to give a quick demo on how to create a new branch from a remote master in Visual Studio 2015 and submit a pull request to merge it back to the remote master branch. This post is for absolute beginners to Git and follows on the previous post that showed how to create your repository.

In your solution open up Team Explorer and the Branches section. Right click on the master branch in the remote/origin server and click on Create new local branch. Make sure that Track remote branch is NOT selected and give the branch a meaningful name, click Create branch.

CreateBranch

If you look at the Branches section you will see the new FixABug branch created in your local repository but it is not on the server yet. To push the branch to the server, right click on the FixABug branch and click on Publish Branch. If you now look at the remote/origin repository you will see the new branch on the server.

Make some changes to your solution and commit them by opening the Changes section in Team Explorer, give the commit a proper commit message and click on Commit. These changes are now committed to your local repository, sync them to your bug fix branch on the server my doing a sync.

Sync

I did the commit and sync in two separate steps to drive the point home of local repositories but you can use Commit and Sync to do both at once. Next we are going to merge the changes from the FixABug branch that is now on the server with the master branch on the server.

Now we are going to create the pull request. In the Branches section make sure the remote FixABug branch is selected, right click on it and select Create Pull Request and watch the seamless integration between GIT and Visual Studio fall apart as you are taken to the TFS web portal to create the pull request 🙂

CreatePull

In this case I am the same person making the pull request and allowing it but usually the person allowing it will be a senior member of the team that will review the change before allowing it. You can add reviewers to this pull request using the reviewers drop down on the right. I’m going to add myself to the reviewers list.

Review

If I now look under pull requests assigned to me I will see this one waiting. As the only reviewer I am going to approve this pull request.

Approve

Now I will complete the pull request and merge the changes into master by clicking on the Complete pull request button. You will have the option to FixABug delete the branch which can be handy if this bug was fixed and the branch will not be needed anymore. If you now look at the master branch on the server you will see your changes.

This was obviously the happy path, in reality there can be merge conflicts and reviewers can ask for changes and pull requests can be abandoned but I will look at these scenarios in a later post.

Francois Delport

Published by

Francois Delport

I am a cloud and devops consultant, technology fan and previously a professional C# developer with a keen interest in system design and architecture. Currently I am involved in projects using Azure, the Microsoft stack and DevOps. I am based in Melbourne, Australia. Email: [email protected]

Leave a Reply

Your email address will not be published. Required fields are marked *