If you’re in technology and haven’t been living under a rock you’re aware of Git. If you’re aware of Git then you’re probably aware of Vincent Driesson’s eventful blog “A Successful Git Branching Model” that has since been implemented and widely referred to as Gitflow. Don’t let the title of this blog fool you, I don’t have a beef with Gitflow. Vincent was accurate to claim he had a successful Git Branching Model. It gets you there 99% of the time for the majority of teams. Still, I have found as far as a team’s ability to be agile, the prescribed flow can run you a foul when indecisive chickens come home to roost.
In Agile the chickens (the customers and executive management) can sometimes interfere (that’s life/reality). For the sake of this post, I am speaking to when executive management promises a feature that was demoed and they want it out yesterday. The problem is they don’t like the other feature(s) that were also in the build. They want it now, if not yesterday. You could argue semantics of implementing agile here; but, at this point “Agile” has left the building and we need to be agile in the original definition of the word.  In my experience it is at this point you suck it up and do as you’re told to those whom provide you a paycheck.  So you set off to get an artifact of exactly what the chickens want.
Well, if you have been exercising Gitflow, you had N+1 number of feature branches and of which several have been reviewed and approved into the develop branch. The problem is after that demo, the big chicken in the corner laid and egg and said “LOVE IT” but I don’t like the N-1 other features. Your product owner is crumbling and they are chanting what that chicken wants. Now you are faced with cherry picking commits and analyzing merges with unwanted features.
A successful solution to this problem involves some slight modifications to Gitflow. I don’t know if I can be as so brazen to say maybe Git Flow 2.0? But this has proven itself to work and if it helps the pigs, all the better!
gitflow_diagram
Several big differences here:

  • No notion of a “future feature branch”. Let’s face it, all features are future branches until someone in a higher pay grade blesses it to life. Until then any mitigating/mingling with another feature is a risk of feature entanglement.
  • Master branch is back to being the source of origin. Gitflow made develop a first class citizen. develop really is a place we want to have immediate integration of our features. We want to have immediate feedback of our conflicts and a place to demo.
  • develop in this flow is best to be automatically merged once the feature branch is mergeable and passes all unit tests.
  • Special mitigation branches “develop/proj-1” in orange. Here the feature/Proj-1 had a conflict. Rather than resolving the conflict in the develop branch or feature/proj-1 branch, the mitigation is stored separate for future reference. Once the mitigation is made it is pulled into develop. This is key to keeping your features de-tangled.
  • develop should never be directly updated by anyone other than your CI server.
  • develop can be at any time destroyed and rebuilt from available features.
  • Feature branches are only branched from master, never from develop. This is important again to keep us premature exposure to another feature.
  • Releases are made from approved features… not the develop branch… not integration.

Overall this modification to gitflow provides immediate integration feedback, firewalls CI from the world, keeps features detangled, your code review doesn’t inhibit integration, and lets you create releases from chicken approved features. Now that’s keeping Agile to its original roots of being an adjective!

“Highest priority is to satisfy the customer through early and continuous delivery of valuable software” – Agile Manifesto