We will now delve into a subject that, although it may seem basic, sometimes gives development teams a lot of headaches. We will analyse some of the most popular branching strategies in GitHub and we will put each of them on a scale.
What do we mean by a git branching strategy? By this concept we mean the methodology for creating and updating git branches that we will implement in our team’s operations.
Why is a git branching strategy necessary? The main reason to establish a team strategy is to be able to make the necessary changes that the project demands in the safest and most organised way.
That doesn’t mean that we have to invent these strategies ourselves. Fortunately, there is a lot of literature on the subject and today we will look at some of the most famous ones. We will try to go deeper into each one of them so that we can easily compare them and choose which one suits us best for our use case.
Trunk-Based Development
Definition
This branching strategy is very curious as it does not require the use of branches. In this case, developers commit their changes to the trunk branch (usually main or master), hence the name, once a day.
But be careful! This central branch must be ready for deployment at any time.
The approach behind this strategy is to create a super agile and rapid deployment space. In this sense, developers are forced to make smaller commits and upload them continuously. The main goal of the Trunk-Based Development strategy is to eliminate long-lived branches. As a curiosity, it is worth noting that the name trunk-based comes from the idea that the project should be like a tree. The central part, or the trunk, is what should be the largest. On the other hand, the branches would be small deviations from the development that need to be pruned.
As we can see, this methodology is based on continuous deployment as a cornerstone. But, in such a deployment scenario, how are products versioned? This is where release branches come in, which serve to stabilise the code without slowing down the development of the trunk branch.
Let’s imagine that we want to release a monthly version of our product. A few days before deployment, and so as not to interfere with the release, we would create a new release branch that would come out of the trunk. This would be a stable place to test and test the release, protecting it from the continuous deployment to which the trunk branch is subjected. Once the release has been worked on, it has been possible to make progress on it and generate some new commits that will later be taken to the main branch with a cherry pick.
Finally, it should be noted that this methodology is closely linked to the concept of feature flags. This condition allows a specific feature to be enabled and disabled. In this way, you can upload new code for that feature even if it is incomplete, knowing that the feature will be disabled.
If you are interested in investigating more about this methodology, I recommend you visit this introduction to trunk based development.
Approach
- In my opinion, this strategy is oriented to small teams. Mainly because if in our team we have 10 developers working on the same platform, it can be quite chaotic to upload a commit ready for production.
- It is also oriented to processes where production release and speed are the priority. From my point of view, it doesn’t make much sense for products that need maximum robustness and security. This does not mean that it cannot be a secure methodology. It takes a lot of work to maintain the security layer, and often there is neither the knowledge nor the time to do so.
- Developing a product for a quick kick.
Advantages
- It is very fast and reduces the distance between team members. Everyone is aligned and generates very short iterations between them.
- Fewer conflicts than in other methodologies.
- Elimination of infinite branches that never end up merging.
- A very clean and easy to read change history.
Disadvantages
- It requires a very mature team and, in my opinion, a lot of experience for it to be applied correctly.
- A very good CI/CD system is required.
- No pre-production environment. You can get a pre-production environment, but you would have to do a very good Devops job. It would be done through features, which can be a benefit as there is no mixing of changes that each of us is working on. However, it also adds complexity to the system.
- In my opinion, having to maintain the feature flags is a big drawback. I have always felt that it can be a source of bugs or an overhead in the complexity of the system that I would not be willing to pay for any methodology.
GitHub Flow
Definition
This methodology, like the previous one, is based on a main branch on which we are going to build our features. This is very important because GitHub Flow puts a lot of value on the confidence that the main branch, in our case, master, provides. Once we release a feature branch, we will be working on that feature until we finish it. The moment we finish it, we can deploy the last commit or status of my feature branch to production.
This approach allows us to make sure that when we deploy a feature, as we do it directly from the branch itself, we will never be deploying other branches that may be in our merged main branch.
As you can imagine, this system coexists very well with continuous deployment environments. What we are looking for is a certain agility when deploying. In addition, and since we are doing it directly from our feature branch, also some rollout capability. The way we can always rollback is by going back to the source of truth, which in our case would be master.
When we are 100% sure that our feature is fully stable and deployed, it will merge with master. This means that what goes to master is always very reliable.
Now, pre-production environments will also come out of the feature branch. So my operations environment will need to be able to switch between branches in order to test the changes before production deployment.
Approach
- Teams of varying size, with Continous Deployment experience.
Advantages
- Keeps a very simple and clean history.
- The master branch will always be very robust. In addition, it allows to have a very secure production space with rollback to master.
- Simplicity of branches, it does not generate a lot of mess of branches or conflicts as they all come from the same point.
Disadvantages
- It is necessary to have a very good operations team. This methodology relies heavily on rollout, rollback and CI/CD systems. For this reason, it requires a lot of operations expertise.
GitFlow
Definition
This is probably the best known and most comprehensive methodology of all. Although there are many detractors, which is perfectly understandable, this methodology is based on two main types of branches. On the one hand, deployment branches and, on the other hand, development branches.
Let’s start by talking about development branches. All development branches start from a fixed branch called develop. This branch collects all the development commits from the rest of the feature branches, which at their birth will come out of it. Subsequently, they will be merged back when they are finished.
The develop branch can act as a pre-production mapping, with all commits that reach development being deployed in this environment. The final condition is that a commit is not uploaded directly to this branch, but the changes will come from merging the pull request of a feature branch with develop.
On the other hand, there are the deployment branches, which are the release, hotfix and master branches. From develop, which acts as pre-production, and once our changes have been tested in this environment, a release-x.x.x branch will be born, which will push the changes towards production. These branches will be the ones that will stabilise a specific deployment over time and, in turn, will allow the changes to materialise in a staging environment.
During this release process we will test the changes in staging and, in case we need to make any changes, we will do it directly in the release branch. Once we are sure that the branch is stable, we can make a pull request to upload the changes to master, which will be mapped to the production environment. This production environment has already passed several firewalls, so it should not contain any bugs. However, if any bugs do occur, the methodology provides for a system to fix them.
If we were to make an urgent change on production and we do not want to go through all the liturgy that such a change requires in this methodology, we can pull a branch called hotfix from master to apply the change and merge back by pull request to master.
This system generates two points of code generation. On the one hand, we have the features branches and, on the other, we have the hotfix and release branches, which will have to end up merging with develop to make the rest of the developments aware of these changes.
If you are interested in going deeper into this methodology, you can visit this git-flow cheatsheet link or this GitFlow workflow link.
Approach
- Teams with medium to large projects, based on robustness and longer iterations.
Advantages
- Robust and robust in multi-version deployments.
- Allows more than one environment before production.
- Ideal for long developments.
Disadvantages
- Complex for agile and fast projects.
- The interweaving of branches slows down production deployment.
- More prone to conflicts than other methodologies, due to commits coming from different points.
Conclusion
Git branching strategies offer developers a methodology for managing workflow and maintaining code stability in production. Trunk-Based Development, GitHub Flow and GitFlow stand out as some of the most widely used for teams with different profiles.
Each strategy has clear advantages and disadvantages that impact the speed, organisation and complexity of day-to-day management. Trunk-Based Development is agile and facilitates continuous development, although it requires an experienced team and excellent CI/CD implementation. GitHub Flow, on the other hand, is simpler and allows for rapid changes, but also relies on strong support from the operations team. GitFlow provides a structured and secure approach for large teams or long developments, but can slow down integration in agile environments.
However, there are more than just these strategies. In other spaces we will explore some others that have been left pending. Until then, enjoy your development!
So that’s it! If you found this article interesting, we encourage you to visit the Software category to see other related posts. See you soon!
