What branching model will you follow when people work on multiple features, a combination of them need to be tested and any feature can be prioritized or de-prioritized anytime.
At an organization I worked for, we were facing similar challenges. This post is about a solution that I came up with and was adopted to solve this.
Why not existing models
There are several other models already that work well, for example, gitflow is widely used, but there were some limitations with gitflow. It is designed to work for places where releases are planned and worked on. The micro-services we work on are the most dynamic part of the infra, so gitflow needed some tweaks. The mental overhead was way too much for the developers since we were not using standard gitflow anymore. Similarly, github flow or trunk based branching models were not suitable for us because they were way too generic for our use case.
A Frankenstein strategy
After, pulling some parts from other models and combining that with our custom deployment strategy, we ended up with following —
- Naming convention from gitflow.
- Branching simplicity from trunk based.
- Continuous rebase of feature branches to keeps rebase to main possible.
- Temporary branches for different testing environments, for example, one prefixed with
staging-. - Squash merging features in different environments.
Working on a Feature
Since we use Jira, a branch should ideally contain the ticket name. The name will be feat/[JIRA-ID]-[FEATURE] or [JIRA-ID]-[FEARTURE], So it will be something like —
Several commits later, we would like to test this, but there are already some people working on feature-y and feature-z. So, To deploy all those features together on our testing branch like staging, we will create a branch with staging- or other related prefix and merge these features there. Github is not suitable for this because any conflict resolution will end up in feature branches which we don't want. Our goal is to have our feature as a atomic unit and conflicts should be solved in this temporary branch itself based on feature priority.
Now that we have our staging branch, We will merge feature-x here.
We use squash merge because we don't want a branching jungle here. Now, to add other two features —
After this, our staging branch will have all three feature as atomic commits and anyone looking at this branch can tell what features are there in staging.
Merging in main
To merge a feature in main, we rebase and merge to main.
Once the branch is rebased, the normal Github PR flow will work fine. It's just that we prefer a linear history and squashed commits, The Pull/Merge request will have the feature branch history if required.
Updating a Feature
If we've updated our feature branch with some commits, we can either recreate our staging branch with required features or replace our commit there.
- find the hash with git log.
- git rebase to that.
- Drop that commit and continue rebase.
- Now, merge squash you branch again.
To avoid this, I prefer an alias that automates most of this —
Continuous Integration and Deployment
- Branches are tested based on prefixes. Anything prefixed with feat/ will trigger feature testing workflow.
- We use manual triggers for deploying testing branches but one other way is to trigger staging or development deploy for branches with staging- or dev- prefix.
- While we currently follow tag based deployment for production as it gives us more control, the main is so stable at this point that a continuous deployment from main will also work.
Conclusion
There is much to it but above is the simple workflow that allows feature to be tested in any combination without complexity ( which I admit, is subjective ) and any feature can be moved to backlog or prioritized. We only need to worry about single source branch. While this is not the best way to solve this, so far, I found it to be much more straightforward in terms of time spent in deployment.