We have all heard a developer saying: “I prefer to do a separate branch. It will be more efficient”. Difficult to refuse without sound counter-arguments.
We may have had the same kind of thinking as a developer or to create our testing strategy. Problems arise in the medium term when integrating our changes into a broader collaborative system.
The management of development branches is a fundamental subject impacting the productivity of teams and, ultimately, that of the company.
This article draws a parallel with the risk associated with the multiplication of branches on a software repository. We share the questions to ask for a branching strategy avoiding pitfalls.
We can feel good (in the short term)
You find the project in the repository, make a clone, start developing.
Everything goes wonderfully. Even the compilation goes smoothly on the first run. This is the ideal way to develop your functionalities with complete peace of mind. In addition, no one asks you to make regular commits on the central repo.
These goals are far from the eyes, far from the heart, and that’s good. You don’t even (yet) have to worry about changes made by other team members. Why, moreover, the focus is your branch.
Days, then a few weeks pass, leaving time to fine-tune the development and local testing of features. This situation is also preferable because the UAT environment is often unstable and lacking in test data.
It’s nice to be able to code quietly without having to coordinate with other team members.
Someone must pay the bill one day or another
The project manager comes back from vacation and asks you if the functionality will be testable the next day in UAT. You answer : “No problem, I even had time to test well” while launching a push to the main repository.
The loading time seems abnormally long, even on your latest Macbook M1. Probably time to get a coffee. When you get back, the size of the changelog and its list of hard-to-scroll conflicts make you nervous.
You spend the next few hours trying to figure out which piece of code to integrate without succeeding in compiling, let alone testing. The next day, despite your best efforts, your branch and its features are still not available.
This short-term trade-off situation is the reality of many teams. Cross-functional collaboration on the codebase is an underestimated subject.
A local self-centered view often hurts
This type of perspective is reflected in the initial quote using the 1st person: “I prefer to work a branch alone”.
System thinking advocates a holistic view of a system, promoting global impact beyond local optimizations only. We need to apply the same reasoning to software development and branch management.
The problem is not to create a branch. We can branch to support a review process while maintaining regular commits or updates. The danger is in the distancing of our branch from our main project.
As humans, we find it challenging to integrate the impact of delayed feedback loops. The more we are personally and emotionally involved, the more difficulty we have to forecast their effect. Think of the attempts at diets practiced with a pot of ice cream in front of a tv show.
We can easily make local decisions that turn out to be costly in the mid-term. We can almost lose sight of the branching model chosen by the team.
We can make branches without use
Branch management models are interesting for putting into perspective several practices for identified problems. Common sense and adaptation remain essential for a value to be captured, like with test pyramids.
Habits easily guide us like intensive checking of emails or notifications. We can also fall into the same trap in managing our branches, creating a branch for any purpose and any use: by feature, by release, by hotfix for each release. It seems endless.
Our goal is to select a branch management model aligned with our organization, culture, and repository model. We preferably have to choose the simpler model to contain complexity if two models seem suitable. These steps are essential to avoid having ten branches losing ten hours per change of function for a developer.
Without going into detail, if Git Flow is the model you have chosen, take the time to identify the factors guiding you towards this choice. You may be procrastinating the treatment of root causes on your development chain.
We may lack courage
Procrastination is a human mechanism passed down from previous generations. Those who have conserved their energy have more largely survived lion attacks and other surprises.
Like the lack of sport for us, procrastination is, on the other hand, dangerous for the software.
We are easily afraid of regularly integrating our code, will the compilation pass? Am I going to block my colleagues? If I push my developments to UAT, how can I successfully test without having datasets and tools available? So many questions of integration too often neglected.
Practices exist such as feature flags, CI/CD quality gates, automation tools, etc. It is still necessary to ensure their implementation and alignment with the objectives of the system. For me, this is where we come to Quality Engineering, which must act transversally and with impact.
For inspiration, you can consult this article recounting the investments and choices defended by Google over the years for the performance of its software chain: How Googles Does Repo (upcoming).
Minimal branches in an integrated system is the key
Centered around a caricatured development experience, we find the crucial elements to consider in our branch management.
We must choose the minimum solution supporting a rapid cycle of iteration of our teams. This means allowing a continuous flow of integration, deployment, and testing in all environments. We need to create an ecosystem that leaves little room for procrastination or the urge to work in silos.
On a personal note, the more complex the system seems, the more questions we need to ask ourselves. Our job is to contain complexity to support the performance of an organization. For that, commits must be regularly deployed until production.
Do not forget the feature flags and other progressive activation mechanisms to avoid that “it hurts”.