DEV Community

Discussion on: Why you should not use (long-lived) feature branches

Collapse
 
jpdelimat profile image
Jean-Paul Delimat

I've updated the title and intro to specify I am talking about "feature branches" as "long lived feature branches". By long lived I mean more than a day or two. Usually when I see "feature branches" used, "feature" is a feature of the project or the product. It is rarely developed "shortly" and sometimes require a week or more to get in. Working on a branch like this is not efficient in my opinion.

I don't see how feature toggles can be used with feature branches though. If your feature is only on the branch and this branch is not deployed to production, how do you use feature toggles to turn your feature on and off?

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

I don't think I'd limit it to a day or two, sometimes a small feature can take longer. It's somehow related to the size of code, and certainly, something taking weeks, has likely gone off into la-la land.

Feature toggles can still be used on immature features that need real-world testing. You don't get to toggle features which aren't in the master branch. I've used these before. Part of the feature includes a toggle mechanism. These should be accompanied with a clear plan of when it becomes the default and the old system is deprecated.

However, if you follow the advice of regularly merging main into the feature branches, you should be able to selectively merge several branches to get a working version. I've done this on several projects as well. Sort of a mix-and-match of branches instead of the feature toggles. This definitely requires regular main-to-branch merging though, otherwise you'll hit all sorts of errors.

Thread Thread
 
anortef profile image
Adrián Norte • Edited

There is something that always bothered me with feature branching and seeing that you seem pretty convinced of them maybe you can solve this for me.

Developer A and Developer B branch out of master at the start of the sprint to do their job and both pull and merge from master frequently but no one is pushing to master so, how do they know they are not breaking each other stuff?

Thread Thread
 
mortoray profile image
edA‑qa mort‑ora‑y

Keep the branches short-lived and avoid working on the same parts of the code. Avoiding the same parts of the code applies to whatever branching strategy you are using.

There's rarely a need for two people to work on the same bits of code in the same period. This can usually be recognized during triage and planning.

In the unusual case where two people are working on the same code, it should be for the same feature, in which case, they can share a branch. And they should probably sit close to each other in the office and communicate.

The moment one of them feels the need to pull from the other's branch, the warning sirens should go off. It sounds like a monster branch is growing.