A git logo, a representation of the gitflow workflow and an illusion of pair programming
Published February 4th, 2015

At Honeystone we all have a very strong work ethic, and jointly, we are always looking for ways in which we can improve our processes. Our prevailing goals, in-keeping with the new year spirit, are to increase productivity whilst, importantly, ensuring we continue to produce impeccable websites, if the quality isn't there, there’s really no point – we are only interested in developing top-notch stuff!

Recently we have introduced several new work practices that 'dev team A' have been trialling extensively as part of the development of the new Honeystone website, and the results have been fantastic!

We now adopt the Gitflow branching model, review each others code, and have even started pair programming.

Pair programming

Pair programming is a wondrous technique that we are deploying at Honeystone. It sees two people working in a team to produce quality code and websites. This can work in several ways, for example in one instance you can have one developer, the driver, writing the code and a second developer, the observer, reviewing each line of code typed. Secondly you could have a developer and a designer working together to carry out in-browser design, incidentally this is another technique we have been trialling to great effect!


We have always used Git at Honeystone for version controlling all that we work on, but recently we have delved in to more advance Git models. Why? Because it gives us a more powerful framework for managing larger projects.

Our Git workflow at Honeystone is derived from Vincent Driessen's Gitflow which he describes here. It's a great read so be sure to have a look.


Gitflow aligns perfectly with our Agile ways. We are currently making best use of feature and hotfix branches at Honeystone, and are finding that this is working fantastically. It means tasks can be distributed, allowing multiple developers to be assigned features to work on independently of each other on the same project, which is absolutely perfect for increasing productivity!

This is all great, however it currently only sees us meeting one of our goals, that is, our productivity being increased. Again, an increase in productivity, however, is frankly pointless if it means our quality is impacted as a result - we all take great pride in the work that we produce. The latest methods that we have deployed at Honeystone to ensure that the quality of our work stays high, are code review and code auditing.

Code review

We now internally review all code prior to it getting submitted to a project. I love it! It ties in wonderfully with our new Git workflow. All feature branches that have been worked on by developers are submitted to our shiny new Phabricator system as diffs against the develop branch, where we can comment, accept or request changes to the code and a whole lot more!

Phabricator is what our heads are in all day, its a feature-rich development hub for complete project management – our home! It supports a vast array of useful tools that make our lives as developers much easier, as well as ensuring we are fulfilling targets to a high level. In a nutshell?.. It makes us build better software!

We use Phabricator predominantly for reviewing and auditing code, as well as browsing our entire collection of repositories. Phabricator also supports other cool features that we use regularly, such as a wiki and an area where we can review mocks and designs before they are used or developed. It even supports the creation of custom extensions, which of course we couldn't resist! Oh yeah, there's a pretty awesome command line interface too! Did I forget to mention that this amazing tool is open source? That's right, Phabricator can be customised for any purpose! The user interfaces across the board are beautiful, it begs the question, how did we ever live without it...

Code audit

The difference between code review and code audit, is that a review is a 'pre-push' workflow and audit is 'post-push', the code is checked at different stages. Auditing code allows developers to push code without waiting for a code review, but in the knowledge that there code will be checked eventually. At Honeystone we do both.


Phriction, the Phabricator wiki is used by us for centralising our thoughts, ideas, processes, best practices, installation and set up guides, everything Honeystone goes in here! Once again, a tool that has proven itself to be something we now couldn’t live without.

For comprehensive information on the Phabricator system, check out Phabricator.org.

So, what are the benefits of code review and how is this changing the way we work at Honeystone?

Fundamentally, code review ensures that the quality of work we produce remains at a high level, it passes through the eyes of at least three separate developers and a senior developer, and only when everyone is happy can the code be merged and then pushed. This enables us to keep productivity high, whilst ensuring quality is not impacted, wonderful!

I also find the process of reviewing code a powerful learning tool. I have been with Honeystone for two and a half years completing my apprenticeship, and am now looking to further build on my knowledge as a Front End Developer. The fact that everything I code runs past several developers, including senior staff, means that I have to do it right! I am a strong believer of 'you learn from your mistakes', and any advice and changes requested from other Honeystone developers only improves on my skills. It is proving to be a great way to learn. It also works vice versa, looking at other peoples code means I pick up new ideas and techniques that I can apply myself in the future – 'oh I didn't think of doing it like that, that's cool!'


Below is a simple example of how Gitflow and code review integrates, and how feature branch could work:

Gitflow is initialised within an existing git repository with the following command:

$ git flow init 

A developer then creates a new feature branch to start work on:

$ git flow feature start my-new-feature 

During the work on the feature branch, the developer will add and commit files as they usually would in git:

$ git status 
$ git add 
$ git commit -m 


The command line interface for Phabricator, Archanist, provides access to many Phabricator tools. Currently we are just using it for Diffusion, the Phabricator diff system. It uses simple commands, using it with Diffusion looks something like this:

After files have been added and comitted on the feature branch, the developer will then create a diff against the develop branch for the code to be reviewed in Phabricator (arc is the command for Archanist):

$ arc diff --create origin/develop 

The developer will then merge to develop and push the changes:

 $ arc amend 
$ git flow feature finish my-new-feature 
$ git push origin develop 

After the changes have been fully accepted, and the develop branch is up to date, a release branch is initiated:

 $ git flow release start 1.1.0 

Any release changes, for example updating version numbers, should committed and then diffed and sent for final code review:

 $ git status 
$ git add 
$ git commit -m 
$ arc diff --create origin/develop 

Finally, once changes have been fully reviewed, the release is merged to master and develop, and then finally pushed.

 $ git flow release finish 1.1.0 
$ git push origin develop:develop master:master 
$ git push --tags 

What does all this mean for Honeystone?

We are all enthusiastic about the new development processes and tools at Honeystone. Not only have they allowed us to meet our new years resolutions of increased productivity and quality, but the entire ethos of the way we work at Honeystone has changed, for the better. We are proving ourselves to be a sophisticated team, more than ever before; we are more efficient and are producing work of an ever increasing high standard. It's fair to say the new processes has seen us exceeding our own expectations! It really highlights the importance of structure for achieving results.

It would be great to hear your thoughts on ideas on any of the above - any questions, comments, shares will all be greatly received! Thanks for taking the time to read.

Best wishes,

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

Sam avatar

Sam Lashenko

I'm Sam, a coffeeholic Front End Developer proud to be working at Honeystone. I am passionate about producing high quality websites and enjoy learning and playing with all things tech. I'm enthusiastic about creating awesome user experiences with the websites I build and continually strive for perfection. Outside work I'll be found down the gym, enjoying a drive or out socialising with my friends.