I’m a Microsoft guy. I like their products, development tools, the whole lineup really.
However, a couple of months ago I started using git (or github if I should be completely honest…but that’s based on git) for version control. Coming from a Microsoft environment with first Source Safe and later on TFS (or TFVC really) it was a bit of a leap to take from Centralized Version Control to Distributed Version Control since that is really the biggest leap to take (I think).
Endjin has very good way of describing the difference as:
My favourite way of describing the difference between the TFS and Git branching models is as follows, in TFS – branching is essentially like the TV Show Fringe in that you have to deal with parallel worlds crossing between those world is a difficult process with severe health risks to the person “crossing over”, whereas with Git is more like Doctor Who: branching is essentially dealing with time streams where you can easily go forwards, backwards and even sideways.
Switching to git really forced me to get to learn the git command-line (yeah, git relies heavily on the command-line). However I do encourage people coming into git from TFS to learn the command-line first before using a UI.
Again, being a Microsoft guy, I do like my UIs so I was very pleased when Microsoft finally revealed that they where now supporting git in Visual Studio 2012. The tooling is still pretty basic but I think for most cases it does do a good job.
Coming from TFS-land however, I still missed the Source Control Explorer so I was very pleased to learn about SourceTree from Atlassian which is a GIT UI for Windows. Still in beta it still does an excellent job at most cases (and it’s free just like git).
So long story there…to put in in very short terms; one of the best things with git is the branching model and speaking about branching, Git Flow is a very popular such a “branching workflow model” that we’ll be taking a look at now and how to use the built-in support that SourceTree offers for it. We’ll also take a look at how I use SourceTree and Visual Studio together.
To put it very short, git flow is:
- a workflow that defines a strict branching model designed around the project release
- developers work locally and push branches to the central repo
- instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features
Setup Git Flow
Let’s open up our repo and click that “Git Flow” button:
Git Flow wants some input from you:
I’ve decided to name my branches and prefixes as above.
Create a feature
The next time you click on the “Git Flow” button (or use the menu for that matter) you are presented with these options:
Most of these “actions” will look the same so I’m only showing you one of them…a feature.
Let’s create a new feature:
The “best practice” is to start your features from the dev branch.
Now I’ll switch to Visual Studio
For me I love that I can commit inside my coding IDE and not have to switch contexts just for doing that so VS does a very good job of this.
OK, I’m done.
I’ll switch to SourceTree again to finish up my feature. Click the “Git Flow” button again.
SourceTree knows my current state (if I haven’t switched branches or anything).
Here we get a couple of options, again up to you to decide but most common might be to rebase onto dev branch.
Oh no…let’s say we get a conflict at this point (or in any stage really). That’s something that VS is pretty good at, let’s switch.
Resolve conflicts in VS
I like the diff tools in VS and the support that the resolve conflicts UI gives me. Finish it up in here and commit.
Optional – push to remote
You can now choose to push the development branch to a remote location (for integration and other to pick up/pull your changes). You can even choose to automatically push to remote when finishing the feature as we saw earlier. I’m pushing manually though:
Depending on you build server and its abilities you also choose to start a CI build for your feature.
I’m using TeamCity which support git and its branching model. A very good article about how to set this up can be found right here.
I’ve setup my TeamCity server to monitor my development branch. And when I’ve pushed:
You can see that TeamCity picked up my changes and integrated them from the development branch.