A Step by Step Guide to using GitFlow with TeamCity - Part 1 - Different Branching Models
When we setup endjin in 2010, there were five activities we did on day one:
- set up a business bank account,
- set up a FreeAgent account, for all our accounting needs
- signed up for Office 365 (or BPOS as it was then),
- registered the endjin GitHub account
- built a virtualised Continuous Integration Environment using TeamCity.
With those 5 simple steps, we had all the systems we needed to run our company.
Quite a bit has changed within the company in the last 24 months, but Git & TeamCity have remained an absolute cornerstone of how we do day to day development and "work smarter"; teaching other companies to do the same has become one of our core consultancy offerings in the ALM / DevOps space. It's no co-incidence that on his first day, our apprentice was shown how to set up and configure a GitHub repository and push his first commit, or that we publish a Step by Step guide to Hosting TeamCity in IIS 7 or that we released a set of PowerShell cmdlets for managing and interrogating TeamCity.
These systems are absolutely fundamental to what we do.
To anyone who has worked within the Microsoft space and has grown up using Visual Source Safe or Team Foundation Server, branching is something to be feared and avoided at all costs unless you want daily nose bleeds.
In these systems, changes are stored as deltas or changesets, the result of which is that in their branching model, branches sit side by side on your file system.
This means that to create or swap between branches has significant overheads, which means if you're developing something like a web application, you have to reconfigure IIS to point at the branch you're currently working on. Also every branch you create requires N amount of disk space, where N is the size of the main branch. Nothing insurmountable, but just added friction.
Along came Git
Git is the total antidote. Rather than pay a branching tax, it's actually a bit more like getting a branching rebate. Git stores changes as snapshots, therefore a branch is simply a moveable pointer to a specific commit (the actual implementation detail is that a branch is actually a SHA1 checksum of the commit).
"I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." Linus Torvalds Creator of Linux & Git
Instead of having multiple branches coexisting side-by-side on your system, in Git creating a new branch involves writing 41 bytes to a file.
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.
vs.
So it's essentially Parallel Worlds vs. Wibbly Wobbly, Timey Wimey. And we all know bow ties are cool.
In the second part of this series - we'll tell you a little bit more about the GitFlow branching model and how to get your development environment set-up and configured.
