For a long time this has been something that has really bothered me. git-flow was first introduced in this article http://nvie.com/posts/a-successful-git-branching-model/. A lot of projects have adopted this workflow. It is a great standard mechanism for managing a project when you need to work with lots of features, different release branches etc..
The problem is that I have had trouble really seeing where the level of complication added to a project by git-flow has really added value to the project that is Agile. Now before we go any further let me add a caveat. I come from a background of favoring a continuous deployment model with anything I develop. While some may disagree with me, this is the model that I think most projects should adopt. This is where you really get your bang for the buck with Agile. But even if you are not doing continuous deployment, if you are doing TDD and CI git-flow still feels like overkill. It seems to run contrary to the reasons that we use TDD and CI.
So why do I feel this way?
First, lets look at the basics of TDD. We follow this because we are aiming at having all functionality of the application covered with passing unit tests that are frequently checked in. While there are certain circumstances where you might have a new feature or piece of functionality that will require major surgery to fix that requires going off into another branch this should be the exception not the rule….
Second, if you are creating all of these branches for each new feature then it really feels like you just lost the benefit of CI even if you are doing CI on every branch. Now you either have to set something up, or create infrastructure to put a CI build on every branch, but more importantly, where is your continuous integration with your main branches such as dev and master when every feature is in another private branch? To me this is a smell. But that is assuming that you push your feature branches up to a main server. The page that introduces the git-flow says that feature branches usually only exists on a developers repo and not origin. At that point we have majorly undermined the purpose of using CI.
Third, continuous deployment, and in my view the spirit of Agile, say that changes should be checked in often and be shippable (even if a story is not complete) at any point in the development cycle. The entire philosophy behind git-flow goes against that.
For some projects git-flow is probably a great tool, but to me I am having trouble seeing how it would add any value to most projects that are following a sprint schedule or doing Kanban. In fact I would argue that if you are doing TDD, using CI, and practicing some form of continuous deployment and feel that git-flow will solve your problems you should take a step back and look at how you are using those tools. Maybe there is a scenario where these would make sense….but I would sooner think that the need for using git-flow on an Agile project is more of a project smell that indicates that something else is broken. I would love to hear what you think, so please feel free to comment.