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.
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.
Currently, a default strategy, successor and watered down version of GitFlow. Agile leaning, lightweight strategy that removes the need of any
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.
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.
Generally speaking, it comes down to which Git platform your repositories are hosted on.