Thoughts about Git-flow

Some time ago, I started to use a workflow similar to Git-flow (based on it but a little more complicated). When the other day I had the oportunity to audit release management procedures on a client, I saw an oportunity to think on many questions about git-flow and the way to apply it on an organization. They were on the path of migrate their model to git-flow and, of course, some questions arise.

In my opinion, Git-flow is a very good model for git projects, especially when you are developing a product, with a bit more static timings on releases. But, when you are working in a service, maybe this model has to be questioned to have some more flows if you want a more continous delivery workflow.

Bug definition

One thing that normally is a headache on defining is bug categories, not every bug is of the same category. Using priority as category, some are a very critical ones, with a fast response and deployment necessity. Every one must agree to tag them as a hotfix, and have to be deployed as fast as possible.
But when thinking in not so critical bugs, response has to be diferent, firefighter developers must be a necessary evil, not desirable evil.

Just as a remember, bug priority must be defined using a couple of elements:

• Urgency: Normally defined by project manager/product owner, it's sometimes a political decision.
• Severity: Normally defined by QA/development. Can be defined this way.

There is also another classification method (compatible with previous one):

• Development bugs: Bugs detected on next version product.
• Production bugs: Bugs detected on production version.

Git-flow bug definition

Git-flow model defines bugs only by this second classification:

• Production bug resolutions are called hotfix and are resolved from production branch and merged into production branch (and spread into development branch).
• Development bugs are resolved directly on release branch (and spread into development and production branch when delivering this release).

Limits

As you can imagine, not all production bugs has the same priority neither complexity. Using only this definition, maybe you won't be very comfortable in using a fast deployment workflow for some bugs you need to resolve. I found these questions interesting:

• Do we have to define two release procedures for hotfix integration depending on its priority?
• Do we have to deliver a new release on every hotfix integration?
• So, is a good idea to treat all production bugs as hotfix?
• How can we manage different priority bugs with git-flow?

As you can see, not everyone would have enough with git-flow model.

Git-flow and continuous delivery

If you are a DevOps fan, you are surely familiar with continuous delivery concept. Defining it in an extremely bad and simple way, we can say that we want to deliver our product as fast as automation permits.

With this objective in mind, we can see that git-flow offers a very good workflow to acomplish it. But again, we need to set a little more questions which need an answer:

• When is desirable to have a "candidate" version packaged?
• How can we reflect our own project status flow into Git?
• How can we get versions with git-flow to set into packages?

Answers depends most on organization, but probably a generic answer is possible. I will try to give some answers based upon my experience on a near future.