Why you should not use feature branches
Isn’t the git history in the picture above nice to work with? There are probably many problems in that repository, but one of them is most definitely the use of feature branches. Let’s see how such a bad thing became such a common practice.
When git came to replace SVN it brought a ridiculously easy way to create branches.
The idea behing git is to ease your pain as a developer working on many features at a time. Not to push branches around and tie them to the whole development process of your team.
When JIRA and others came along , companies like Atlassian started to heavily promote the “git workflow” and feature branches. The “Create branch” button appeared in your JIRA tasks and boom, feature branches were born! Atlassian tells you all about it in this interesting article. I like Atlassian’s products very much. Keep in mind though that their core business is tasks management for development teams. The more tangled it gets with branches and code, the better.
Ten years later, feature branching is a standard in most teams, when in fact it doesn’t bring any benefits to your bottom line: release quality software to production. Not only feature branches provide zero benefit, they actually slow you down!
“The feature is ready. I just need to merge it!”
I’ve heard this way too many times. This falls in the same category as statements like “It compiles so it works”.
In practice the merging leads to the “unpredictable release syndrome”. It can be quick or evince a major incompatibility, which needs fixing in a rush. You are either lucky or … your timeline shifts and code quality drops.
The real problem with feature branches is the reason they are so popular: they pump a developer’s pride and make you feel good about your work.
Your feature branch is your own perfect garden and you can keep it clean and shiny. But it is separated from the other gardens of your team. The more you work apart, the harder it is to reconcile.
I am a big fan of the management book “The goal”. It shows how over time people tend to use metrics that highlight local optimums of a process because it is more comfortable. They just lose focus on their global bottom line. The book is about a production plant, but the analogy stands. Your feature branch is a local optimum with high quality code. It may also be so far off the main branch that it is of no use for the upcoming release.
Trunk based development to the rescue
As the name suggests, in trunk based development the whole team pushes continuously to the main branch. You can still call it develop instead of master if you want to keep part of the trendiness of feature branches ;)
Here is a detailed description of the idea. I have no affiliation with the linked website. It is just a great overview of the concept.
When you push your work to the main branch on every push, the amount of code to merge is way smaller and it becomes trivial. There is a far greater benefit though: you and your team can spot problems before they become painful. It might be that your refactoring clashes with another feature. Or you are drifting off from the project conventions or architecture patterns. This is the real value of the process. As I preach in any place I find myself in:
It is teamwork that makes or breaks software projects.
Working days on code that will never get to the release on time is the biggest failure there is for a team.
Another upside of pushing to the main branch is that your changes will run live in some environment. It is always good to deploy and battle test your code, even in progress, in some real deploy.
“WIP” in the main branch?
If you read so far you are probably thinking “This is crazy, how can I push my half done work to the main branch when it will probably get deployed to production very soon!?!”.
Keep reading, all the objections you can think of are wrong.
How can I expose unfinished work?
Use feature toggles. They can be environment variables or whatever suits you best to turn on and off your work in progress. Make it defensive of course so your half finished code does not get active in production by mistake.
Your whole team will love this: you can activate code on any environment at any time to see how it looks or performs. Testers can prepare testing early on. Product owners can comment on your work along the way. It is all live and easy to access for everyone! If your work is like just started this provide little value. But evil lies in the details. It usually takes half the time to get to 90% completion and another half to finish the remaining 10%. Sharing your work in this state of 90% completion is always a good idea ;)
Another thing that comes for free: you can turn the feature off in production if a problem arise after deployment. After a few days or weeks, once the feature runs smoothly, just remove the toggle from the code.
What if I break the main branch for everyone?
It is 2019. If you don’t have a continuous integration setup that builds and runs tests automatically … then set it up yesterday. If you break anything you’ll be notified before it becomes a problem for the whole team.
There must be a code review before we merge anything in!
That’s a valid point. Code reviews do not need feature branches though. If the code review culture is strong in your team then it can very well be done on the commit to the main branch. The reviewer would stop by the author of the commit and discuss what needs to be fixed. The fix would come in another commit. Even better, have the code review together before pushing the commit in the first place.
If you prefer to do code reviews offline, one could very well make a branch for a commit and create a pull request for it. This seems overkill though. The main thing to improve here is probably not the branching model, but the code review process.
I want to see the code that is related to a task
If you have a given branch per feature then it is easy to track code back to your agile board. You can navigate from a task to the branch that implements it.
It sounds cool, while in reality this is useless! How many people can you have on an agile team? Up to 5? Up to 10? How hard is it to ask the guy running a task or story what commits you need to look at to deep dive into the implementation?
After some time, once tasks are completed for a long time, linking tasks to code does not make sense anymore. Developers rely on git blame to know the who, on code content to know the how, and hopefully on comments to know the why.
The cherry on the cake: opt-in on new features
It became common to see major UI features or updates released using an “opt in” approach. Github, Bitbucket, Gmail, … to name a few.
The concept is that major changes are introduced using a banner “Hey we have this new feature / improved dashboard / whatever. Click here to try it out”. You can opt in, and usually opt out as easily if you don’t like the change. This is a very good adoption testing strategy as it involves the end users in the decision process. If people opt in and stay there it means you are improving the experience. If they opt in and out … you know you’ve changed things for worse.
If you are using feature toggles from the start, exposing these on a per user basis at run time becomes very easy.
If you never thought of trunk based development as an alternative to the feature branch mantra, I hope this article gave you some perspective and will to try it out.
The best thing is that to get there you’ll need to setup or improve every other aspect of your process (CI, automated tests, code reviews). This is a good path to take. We obviously recommend Fire CI as a continuous integration tool.
Remember that your bottom line is to put quality software in front of your users. The closer your code is from the production environment at all times, the better.
Published on by