#8 When Can't Trunk: Meet Short-Living Branches
Trunk-based development is a fantastic engineering practice which is simple but not easy to achieve. Before you get there, you can try to shorten your branches and increase PRs quality.
You are part of the development team. There is a task that needs to be implemented. You create a branch for it. After one to two weeks of development, you are finished. You have probably been synchronizing your branch with the main one multiple times, or you did it only in the end.
Problem number 1: You must regularly merge changes from the main branch or rebase. If you forget about it for a day or two, it may cost you a grimace or two on your face.
Problem number 2: If you do it in the end, there are usually many conflicts with other changes done by others during this time. This quite often leads to anger, sweating, and several bad words.
Finally, you synchronized your branch and are ready for a pull request. Now, the reviewer sees something similar to this view:
This branch contains a feature to download a file. There are 45 commits that touch 82 files. 4571 lines of code were added, and 45 were removed.
Problem number 3: The reviewer must focus on the entire feature in his code review. He must either go commit-by-commit or through each of the 82 files. PR can include changes related to business logic, infrastructure, architecture, code formatting, renaming, and many more.
As you can see, there are various areas to focus on. If the reviewer focuses on each file only for a minute, it will take him at least 82 minutes to finish it. With such an approach, critical issues might be easily overlooked.
What about architecture analysis, design patterns, and testing the outcome to see if it works as desired? There is a high chance that, in the end, the reviewer will be exhausted and demotivated to handle such an amount of work. Another (really bad) option is that he goes with LGTM! (Looks Good To Me) and PR is immediately approved.
The review goes on, and after 4 hours, you get the response. It looks as follows:
Problem number 4: You see 53 comments. That is a lot! You need to go through all of them. There will be things like cleaning unused namespaces and variables or renaming methods. There will also be comments that are discussable. And the hardcore ones - switch it to this design pattern, change architecture, in general refactor quite a lot of code. After several rounds of ping-pong, you are finally ready to merge it. Oops, you need to rebase. There are conflicts. Finally, it is merged into the main after 2 days full of review & rework rounds. There is a high chance that, in the end, you will be exhausted. It might be even worse; you might start thinking if you are the right person for this job.
Let’s go back in time. Instead of creating one branch for a task, you analyze it first with your teammates, and they want to help you implement it.
After some time, you decide to split it into small subtasks:
Prepare download icon design (approx. 1-2 hours)
Integrate the download icon into the file row without any action connected (approx. 2-3 hours)
Handle business rule number 1 required to generate download link (approx. 2-3 hours)
Handle business rule number 2 required to generate download link (approx. 2-3 hours)
Prepare technical implementation to generate download link (approx. 4-6 hours)
Connect technical implementation with business rules (approx. 2-3 hours)
Implement endpoints (approx. 2-3 hours)
Trigger download action on clicking the download icon (approx. 1-2 hours)
Now, you are ready for short-living branches, the ones that live for a short amount of time after the creation. What does a short amount of time mean? Together, decide what fits your team. Sometimes it will be a couple of hours, sometimes 1-2 days. If the latter, try to reduce it occasionally to make it shorter.
You should ensure the branch has been merged and closed during this time. This way, the speed of change is entering previously unimaginable levels, and more and more people are increasing their motivation.
Yeah, my code is merged!
Great, there are a small number of changes, and I will try to grill it!
The feedback loop is shortened to a minimum. Here are my recommendations for short-living branches:
Recommendation number 1: Analyze and split. Divide your work on a task into smaller pieces. From this moment, each subtask can be treated as a separate, short-living branch, and you can easily parallelize the work with your colleagues—each will take one subtask and create its own branch.
Recommendation number 2: New work discovered = new branch created. Whenever you find a new subtask to do after the initial split, treat it as a new, short-living branch (add a subtask and start your work).
Recommendation number 3: The shorter, the better. Do not go with more than 1-2 days for each branch. Even if you have to merge changes to or rebase your branch at the end of work, it will not be as much as it would have been after 1-2 weeks. I try to keep it alive for a maximum of 4-6 hours.
Recommendation number 4: The less, the better. Try to keep your pull requests as small as possible. This way, the reviewer who looks at your code, where 4 files have been changed and 8 commits done, will be motivated to look at changes in-depth. Observation from my side: the fewer files are in PR, the faster feedback I get—sometimes, it is ready after 10 minutes from the request to review, and I am able to merge.
Recommendation number 5 (advanced): One area of change, one branch. This is usually achievable after some time. For example - during your work on the short-living branch, which is responsible for adding an icon to a file row, you discovered that it would make sense to move 20 files to another namespace and another 15 files to a different one (not directly related to the change you make). I suggest creating another short-living branch that will include only these commits.
In my experience, changing your thinking to short-leaving branches brings many benefits—both for a product—increased quality because of deep focus during code reviews—and for team members—increased motivation. Furthermore, they give you a solid foundation to eliminate branches and PRs and eventually move to trunk-based development.
Do you use short-living branches or something similar? Let me know!