Is Feature Branching still (or ever) considered a bad practice?

Question

Coming from the TFS world and having just gotten comfortable enough with Git, I am about to propose to my team that we should incorporate the Gitflow workflow as pointed out by the famous article by Vincent Dressen going forward.

Almost all modern-day literature surrounding branching strategies voice the effectiveness of the Gitflow workflow, which is an extended version of feature branching, but dated articles from influential engineers, such as Martin Fowler's Feature Branch article (2009), discredit feature branching in general in favor of continuous integration.

Some of his critics stated that Fowler's opposition to feature branching was in part because he was using SVN as his VCS, which was an ineffective tool for merging and therefore led Fowler to recommend a branching anti-pattern "merge paranoia".

Fowler then responded in 2011 by saying DVCS systems may make merging easier, but they still don't solve semantic conflicts. Now in 2014, we have language aware merge tools such as Semantic Merge, which might solve this problem altogether.

My questions are

1. Is feature branching and continuous integration mutually exclusive?

2. How relevant is Fowler's article in modern day development, especially with our accessibility to tools like SourceTree, Git, Jenkins, and other code review software that make feature branching and the like much easier?

Answer 1

In my experience, it depends on where your feature branches are being created. If you are following a fork and merge model, where the feature branches are created on your fork, then I don't see any issues. From the point of view of the main project, it's still just a single (mainline) branch; the only place that the feature branches show up is in your fork, and the only reason for using them is to isolate the changes that you are submitting (in the form of a pull request) against the main branch.

Answer 2

If you look at the Wikipedia article on Continuous Integration (today), you will see that it is about merging with a single mainline daily. Based on that, I would say the answer to your question number one is yes, but that does not preclude using a feature branching strategy.

For your question, number two I don't think the answer is quite as straight forward, but in my experience, creating branches is easy, and merging them after entropy is not. I still find Fowler's article to be accurate.

Answer 3

1. No, you can setup CI on both mainline and each feature branch there is no issue.

2. It is still very much relevant. Although automated merging algorithms are getting better and better including some of the semantics based merging, it is still impossible for a computer to infer meaning. Until we get true computer intelligence, this will still be a problem. The question is, what is the % of cases where automated merge produces incorrect result and what is the % of those case where it knows it would produce incorrect result. Essentially, if you could automatically infer all the cases in which automated merge would fail, you would be able to route those to humans. But that is also a hard problem to resolve. The worst case scenario is not when automated merge is unable to merge code, but when it can merge it, but merges it wrong - usually in semantics or resulting in race condition or some other issue not easily identifiable without human insight.

In general feature branches are very useful to isolate changes in a small team that works on a feature where you are either unsure of its quality, the code could adversely affect other larger teams working on the project or you are not sure if the feature will make it into next release.

You want to limit the use of feature branches to minimum amount of time possible. Merging code between two branches with complex sets of changes could be difficult and require a lot of time, the difficulty raises more than o(n) with n being the sum of changes on both branches. Generally going over 1 month you have to have a really good source control system, good code interfaces/architecture or OCD developers or combination of those three.

About 25% of time in a project should be dedicated to reduction of technical debt, which mostly includes refactoring of code. Feature branches are a problem during refactoring, because a merge of pre-refactoring and post-refactoring branches can be extremely difficult. For this reason you want to make sure that all Feature branches are merged before you start refactoring.