Branching code based on a feature. All developers have most likely done this. If not and you have always pushed your changes to a master branch, ignore this article. For the rest of us let’s think about what we are doing every time we create a new branch for feature development.
So the main reason why most of us create feature branches, is so we can code without disturbances from other developers in the team, or simply because we don’t want to commit our unfinished changes to the master branch, and therefore “accidentally” have our code shipped to production. Sounds like great reasons right? Well for a long time it made sense. Now not so much.
Did you notice I flagged the word accidentally, in the previous paragraph with quotations? This is intentional. Merging code into master should never be considered an accident. In fact I feel having code in master as quickly as possible is the best practice we could have. Why? Let me explain.
Lets first think about what we are doing the minute we branch off master for feature work. We are saying that we essentially do not trust our CI and CD process, if we even have one. That’s point number 1. Point number 2 is we view delivering unfinished code for our features to production as a bad thing. This second point is somewhat valid, however with a proper feature toggling strategy this too, can be overcome.
What’s most important is when we branch for feature development, we are hiding our work from our teammates. What does this mean? Well potentially it could mean catastrophe. If 2 developers are working on similar stories, it’s possible time could be wasted where both developers are building the same functionality to achieve a particular task at the same time. It’s only once one of the developers merges their entire feature into master that the other one finds out about it, and then has to “refactor” his code, meaning more time wasted. Sure we could communicate who does what, but be realistic here. Not every developer will understand what another developer needs to do in order to complete their story all of the time.
Now don’t get me wrong I’m not saying not to use branches at all. I just feel the main reason we need one is to make reviewing our code changes easy. To most developers, code reviews are usually associated with finished features, and that is why developers wait so long to do pull requests and sit inside these “long running branches”. I think this is a mistake. By utilising feature toggling in your code base, and ensuring that your feature can’t be run in production until it’s finalised, this allows us to push more frequent changes to master, via regular pull requests.
The outcome from this is less time wasted based on potential refactoringbecause a fellow developer pushed in a big feature change before you. Other benefits is it reduces conflicts, reduces complex branching strategies (ie branching off branches etc), and other developers can also quickly see the work that is being done by others and even use some of it. Sure working in this manner does mean that code reviews need to be done more regularly by your peers, however these code reviews are a lot smaller and easier to understand.
If you haven’t guessed it by now, yes I’m referring to trunk based development. Trunk based development heavily relies on your CI and CD pipelines being top notch. More importantly for trunk based development to work, you also need to ensure you are heavily covering your code with a lot of tests (though feature toggling can alleviate a lot of that heavy lifting to start off with).
In conclusion I truly do feel that we are at a place now that we should be trying to implement a system that allows us to quickly release code. We need to improve the visibility of what all developers are doing, and also prevent delays due to refactoring because of sudden long running feature branches being merged into master.