Essentially you need to come up with a good Git branch strategy as it’s often overlooked. There are few strategies you could pick off and call it a day but on a long run you might face certain issues most probably related to how you want to handle different environments, how often are PRs merged into the main branch a day, how are they handled, team size, collaboration, and so on. Besides master or recently called main, develop and feature are your typical Git branches. These strategies are also referred as Git flows.
Prerequisites
- Git
Solution
GitFlow
When I first started my career as a DevOps engineer, I looked at the GitFlow graph and said to myself: Bruh! Noone’s gonna manage that number of branches.
Just search for any images on the internet, you got the following branches:
master: the main branch → production environment.develop: a steady working preprod / staging environment.feature: develop new features off the develop branch.release: finalize everything and bug fixes from develop ready to be merged back to develop and master.hotfix: high priority bug fixing branched off the master branch then merged back to master.
Practically, an outdated model since it doesn’t go hand in hand with current DevOps state including fast development and release cycles. But, it can be a great starting point for beginners and juniors.
GitHub Flow
Currently, a default strategy, successor and watered down version of GitFlow. Agile leaning, lightweight strategy that removes the need of any develop, releaseor hotfix branches. Just main and feature branches, and that’s all.
The only downside I could think of is that you are one bad merge away from screwing up the production deployment.
Since GitHub is part of Microsoft, Azure DevOps adopts the same strat.
GitLab Flow
Addressing the GitHub and Git flow issues is part of the GitLab flow.
GitLab configures your development branch as a default branch and a starting point. Also, supports isolation between environments by allowing you to “connect” environment branches to their respective GitLab environments such as: staging, preprod and prod. There is also a feature related to release branches for instance 1.2-stable.
But, hold on. This is reinventing the GitFlow wheel, right?! It’s a simpler form than GitFlow though.
It may sound confusing, but you can think of it as GitLab isolating and protecting the production branch from the main branch, if that makes sense. Prevents causing any issues when merging into the production env.
Trunk-based development (TBD)
The true gigachad so-called Trunk-based development where you have this idea of a trunk branch == main branch and short-lived feature branches.
Think of it as an ideal version of GitHub flow. Approved amongst the elite FAANMG-type of companies.
Instead of focusing on building full features, waiting for 2-4 weeks of development and punching walls whenever you have a dozen merge conflicts, TBD focuses on small changes and bugfixes merged back to “trunk” multiple times a day, hence multiple deployments to production. This actually aligns with the core Agile - DevOps - CI/CD practices.
Conclusion
Generally speaking, it comes down to which Git platform your repositories are hosted on.
To find more neat Git commands and hacks, simply browse the Git category. Feel free to leave a comment below and if you find this tutorial useful, follow our official channel on Telegram.