Monthly Archives: January 2012

Des tweets et des plus n°12 – Mega Busted


The GitHub Job Interview: You come up with a cool idea of an open-source project. This becomes your company’s development sandbox. Candidates are asked to then contribute to the project in some way

Languages, Verbosity, and Java: “A little redundancy in a language is a good thing. It’s important for readability.” Joshua Bloch

Amazon DynamoDB: A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries

Average Is Over:  the reason we have such stubbornly high unemployment and sagging middle-class incomes today is largely because of the big drop in demand because of the Great Recession, but it is also because of the quantum advances in both globalization and the information technology revolution

Des tweets et des plus n°11 – Geeks win

Shame driven development:  it was throwaway, one-use code so didn’t have any unit tests. I was embarrassed. […] the only way to go fast, is to go well

Cleaning a kitchen is a good metaphor for Refactoring: Neither would a cook accept that I go into his kitchen and say: I want my steak half the price, can’t you not clean the kitchen today? In the software world we let people tell us, do it quick and dirty, you can clean up after, when we have the time.

How netflix get out of the way: Who has junior engineers, graduate hires and interns writing code? We don’t. We find that engineers who cost twice as much are far more than twice as productive, and need much less management overhead

CQRS:  est un modèle d’architecture système qui sépare la partie lecture de données (query) de celle qui les modifie (command) de manière à produire un système extensible, distribuable, et fournir quelques avancées utiles qui rendent la maintenance du système moins pesante.


Another Git branching model

We’ve switched to git at work a few month ago. Not an easy task but the rewards are worth the trouble. Our branching model was based on Git Flow because it’s well documented and gives you a structure to start with DVCS. Well, after a few iterations it wasn’t working as expected in our context. So we had to come up with our own workflow.

I guess Git Flow works well on a clean code base with good test coverage. But on legacy code, where one feature means two regressions, a release branch is like the vietnam war, you never know when you will get out of it. That was one of our main problem on subversion, we were creating release branch to go to production. And it would take forever to actually ship the code. Meanwhile all other development efforts remain stuck.

I though that cheap branching and merging in git would solve our issue. But cheap merging is not enough, you also need to be able to easily pick what to merge. And with Git Flow it’s not easy to remove a feature from a release branch once it’s there. Because a feature branch is started from develop it is bound by its parents commits to other features not yet in production. As a result, if you merge a feature without rebasing you always get more commits than wanted.

So here is the workflow we use to solve those issues:

The main branches

We have three branches with an infinite lifetime based on the classical trio (dev/test/prod):

  • master
  • staging
  • develop

Master is the same as in git flow:

We consider origin/master to be the main branch where the source code of HEAD always reflects aproduction-ready state.

Staging is a bit like develop in Git Flow :

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.

Develop is there for continuous integration, this is where we constanly merge all the changes to detect bugs and conflicts as soon as possible. The source code in the develop branch never reach a stable point where it is ready to be released. Instead only some feature branches reach a stable point. Those stable feature branches are merge into the staging branch. Since feature branches were created from master and not from develop we can pick individualy which one will be merge to staging. In fact this is the main point of this workflow: We can easily choose which features will go into production next. 

To release the code to production we just merge staging into master.

Feature Branches

All work is done in feature branches which can be merge into

  • master for a quick fix in production
  • staging for bug fixes
  • develop constanly for continuous integration

Since we use github we usualy do a pull request to merge feature branches. We don’t always follow the rules and commit on master and staging happens, they are merge back to staging and develop. The only place where we don’t commit is develop 😉 (only merge commit)


Git Flow was not working for us, but by creating feature branches from master instead of develop we gained the ability to easily choose which features we release next. This gave us much more flexibility and got us out of “vietnam release branch”.

Now I should tell about all the best practices to make this workflow really work, but I’m lucky, someone already wrote them down.

And you, what is your branching model ?