We've recently taken on a third developer (well, second developer, but I'm also counting myself), and our ad hoc workflow took a battering. So we upgraded.

As I have blogged previously, we use gitflow as our workflow, and as I may have mentioned, we use Trello to track what we're actually developing. When it was just @stevejalim and myself, this worked perfectly - with HipChat gluing it all together. We intrinsically knew what to put on a branch, what was a hotfix, and when to develop on dev.

However, when we took on @cpwood things took a bit of turn - the two of them combined were generating way more commits than I could track, and all of a sudden our inability to match commits to features (something I was used to, and missing, from managing much larger teams with Fogbugz) was becoming a problem. Knowing where something was, and how on earth to isolate it as a deployable entity was nigh on impossible.

Problem is, we love Trello, and didn't want to give that up and move to a more traditional integrated issue tracker / source control like Github, Fogbugz/Kiln, JIRA/Bitbucket. For one thing, my co-founders can look at Trello and understand what's going on - asking them to review Github issues isn't really reasonable. So we had to improvise.

The solution we went with relies on the use of gitflow, and pull requests - which I guess are now ubiquitous, even beyond Github (e.g. Bitbucket supports them). Gitflow gives us a clear model for branching - hotfixes from master, and features from dev, which we match to Trello colour labels. Each card then begets a branch - I know this sounds crazy, and in a non-DVCS world it would be, but it seems to work. This is how it works:

1. As 'product owner' I manage the Trello board, and ensure that each card is self-contained (referencing dependencies where appropriate), and correctly labelled (Hotfix, Feature).
2. Cards are ordered in priority - so that @stevejalim and @cpwood simply start at the top (in theory - they are too clever and opinionated to simply do what they're told ;-)).
3. Card is moved from 'Not started' to 'In Progress', appropriate branch is taken and development commences.
4. On completion, the card is moved to 'Complete, ready to merge' list on Trello, and a pull request is issued via Bitbucket.
5. I get a notification, and am then responsible for reviewing the commits, approving the merge, and then merging.
6. On merge, I move the card to 'Merged, ready to test', and deploy the dev branch to our dev environment, where everyone can see it.

This is what it looks like in practice:

This gives me the power to delay merging certain features, whilst deploying others, which in turn gives much better visibility to Chris and Shib, who are interested in 'when is feature X getting deployed'. It also gives a really clear audit trail - I can see when a branch was finished, who approved it (generally me, so the blame tracing is fairly basic), and when it was merged back in.

I realise that neither git-flow nor pull requests are new, however it turns out that something as simple as coloured labels means that Trello can bind these two processes together to create a really compelling workflow.

The most interesting thing (to me) is that we are by any measure a tiny development team, and yet we've already reached the point where a sophisticated workflow and branching strategy is a requirement**.

Lovely-jubbly, as we say in the UK.

**Strange thing is, it's not that long ago that I remember working with Visual Source Safe, and we although we obviously still shipped software, I have no idea how we did it. (Anecdotally, @followjimbobdog and I once shipped a product v2 that had no bugs - literally. Nothing came up in testing at all - it just worked. And it was written in embedded Visual Basic. Just sayin'.)