Visual Studio Team Services comes with many capabilities and features to support your version control needs. One of these features is an unlimited amount of free GIT repositories. The other valuable features are integration of work, build and release out of the box. This is a small how to when you want to start with GIT within VSTS.

The start, setup structure.

Create your VSTS account. While you also can create an unlimited amount of VSTS accounts it advisable to think of how your setup your structure.

You can create all projects in one VSTS account or you can create a VSTS per project. Defining a projects scope is already challenging for many systems.

A good decision maker can be to look at ‘single entities of deployment’, define the parts of the system that can be deployed in isolation. When a system can be deployed in isolation it needs its own GIT repository. Maybe even its own project, or maybe it can be combined in the same project because the system parts have the same cadence and a tighter dependency. For example an API and its Angular Frontend solution.

7. In Visual Studio (make sure you have develop checked out) add the Git ignore files. Depending on the project you are planning to make. See this collection of Git ignore files https://github.com/github/gitignore

8. Create the solution you want to make for this project. Within Visual studio make sure you disabled the option ‘make new Git repo.’

9. Stage, Commit and Push your first changes to the develop branch VSTS.

10. Create Build definition for the develop branch. Make it succeed.

11. Configure the Branch policies for the develop branch via settings. Select the just created build. From now on team members only can add changes to the develop branch via a Pull Request.

12. Do the same for master. First merge the develop in to master, commit and push the changes.

13. Also create a build and set the branch policies for the master branch. Now no one is able to make changes to the master branch without a Pull request.

14. Optional, setup a release for the master branch (and develop).

A note on the release in this flow. When you connect the same build as the pull request validation build to the release for continues deployment, the release will start. This is something you don’t want. So there is a need for an additional build, which is triggered after commit, a continuous integration branch. This one can be connected to the release.

And we are all set, ready to do some real work.

The real work exists of making feature branches, code changes, merge the changes and make pull request.

Make feature branch.

Name the feature branch (the good thing the PBI is already linked for traceability.) you also can add the task.

Next, do your coding magic. But, first get the feature branch within Visual Studio. (note: often you have to sync before you see the newly created feature branch).

Now you can do your coding magic. Freely commit and branch your feature branch at will, till you and your teammates are done and ready to make a pull request to develop. Don’t forget to publish the branch and, or push the commits.

Make the Pull Request.

Before making the Pull Request you have to validate if the changes in the feature branch don’t interfere with the changes in the develop branch, maybe some teammates made some breaking changes for your story. So first, checkout develop and pull all the changes in.

Validation will start and when all good (ping the team for a code review). The Pull request can be completed and the changes merged in to develop.

After the pull request is completed and the code is merged in to the develop branch the CI build is kicked off. When the CI build is done the CD release will continue (see note at start up, after bullet 15).

Ready for a release.

All validation done, all coding done, sprint done, ready for a release. Make a release branch from develop and put it as a Pull request in the master branch.

Sync develop and make a release branch.

There is some time for a few minor last changes (rather don’t do it, than you also have to make a PR to develop) and make a PR to master.

Builds starts, reviews done and complete the release. Same note here on the release and the two builds (PR build and CI build for CD release).