It’s been over a decade since I first learned about GitFlow. Ever since, I’ve followed it — kind of. I never bothered to explain it to myself or another. Like why sometimes I deviate from it. i.e. release branches got cumbersome so I stopped using them.
With GitFlow, there’s a master and develop branch. And developers work on feature branches that get merged back into master. Beyond that, things have diverged. It depends on team preferences, client requirements, or CI/CD tools. I never revisited or reconsidered my branching strategies. Instead I went with the flow. (Pun intended.)
Why I Started to Rethink the Branching Strategy
I was setting up a new repository in GitHub for an Edge Delivery Services project. Following GitFlow, I created a new develop branch for dev integration. And left main for production.
But Adobe's best practices on on GitHub do not mention a develop branch. Instead, pull requests go into main. Why would changes go straight into main, the production branch? I began to feel like there was something I was missing.
Three Branching Strategies
In my quest to better understand the main branch, I found that there are two other git workflows. GitHub Flow and GitLab Flow. These two came about because of the complexities of GitFlow, which tend to complicate CI/CD. It also doesn't make sense for some projects. Such as websites which are not concerned with keeping versions. There is only one version of a website, and if something breaks, you fix it and deploy the update. You never go back, or patch a previous version.
Considering GitHub Flow
GitHub Flow makes everything simpler. Like in GitFlow, developers use feature branching. But that is the only similarity. There is no branch reserved for development. There are no release or hotfix branches. Everything goes into main, which is production-ready and deployable at any time. This is more aligned with CI/CD in which continuous integration happens on the main branch. And that is continuously delivered to production.
There is a risk that unfinished or unstable code can make it into main. Adobe's best practices reiterates some things we can do to mitigate this.
Enable Branch Protection Rules: Prevent direct pushes and force pushes to the main branch.
Require Pull Requests and Reviews: Only allow changes through PRs with at least one approval.
Enforce Status Checks: Ensure all tests, linting, and performance checks pass before merging.
Considering GitLab Flow
GitHub Flow relies on tests and code reviews to ensure main remains stable. You need to have good unit tests, linters and eyeballs on a PR. But, I remain skeptical. If main breaks, it can affect dev integration, QA, UAT or production. This is the gap that GitLab Flow fills in.
Feature Branching
GitLab Flow starts off like GitHub Flow. With feature branching into main.
Environment Branches
GitLab Flow adds branches to isolate working environments. And you can have as many branches as you need between main and production. Such as a QA or UAT.
Once you have enough stable features in main, it gets merged downstream. Until it reaches production where it gets tagged. If a breaking change gets into main, downstream branches will not get affected.
Hotfix Workflow
Should an issue show up in production, it gets fixed via a hotfix workflow. It starts by creating a branch from production. Merging it back into main via a PR. Then merging (or cherry-picking) downstream until it reaches production. Where it gets tagged as a minor fix.
In the diagram bellow, there were no new features introduced after the last release. Merging downstream would have been acceptable. But if untested features in main had been present, cherry-pick is the better option. To avoid those features getting into production.
Also, it is important to point out that changes should always flow downstream from main. This ensures that they get tested in all environments. Before getting released into production.
Why Gitlab Flow May Be Better for Edge Delivery Services
GitHub Flow works great in a lot of situations. You can even achieve the same result as GitLab Flow. By deploying main to different environments with a GitHub workflow. The problem is that with Edge Delivery Services, there is no "environment" to deploy code to. Instead, there is a 1:1 relationship between the code branch, and the testing URL.
If you are following GitHub Flow, your feature/foo testing URL would be
https://feature-foo--my-site--my-org.aem.live/
And when the PR gets tested, reviewed and approved, it would go to production at
https://main--my-site--my-org.aem.live/
If something goes wrong, well there is no hotfix flow. You fix it on main 🙂. I mean how bad could it be? Your PR had a narrow and well defined scope? You had good unit and end-to-end testing? Someone did a code review? The QA engineer has good test cases? Then a fix should be quick and easy. 😏
If you are following GitLab Flow, you will still use the the feature and main URLS. But you are adding the stable branch urls
https://stage--my-site--my-org.aem.live/
https://prod--my-site--my-org.aem.live/
Combine this with a repoless configuration. You can point to content in different environments.
https://stage--my-site--my-org-stage-content.aem.live/
https://prod--my-site--my-org-prod-content.aem.live/
Where my-org-stage-content and my-org-prod-content are repoless config sites. But pointing to different content sources. Check out: Repoless Stage and Prod Environments.
Conclusion
GitHub Flow is simple and easy to use. Teams use it when they want to work fast and keep their website or app updated all the time. Developers make their changes in feature branches. Then test and check their work through pull requests into the main branch. This way, the main branch is always ready to go live.
GitLab Flow gives more structure and safety. It uses special branches for different steps. Like testing and reviewing before anything goes live. This helps catch mistakes early and keeps bad code from going to the final version. It also keeps the release process more organized. This is great for projects where being careful and going step by step is important.
You may have already started your Edge Delivery Services project. And you have worked out a branching strategy. If you are like me, you may have gone with the flow. (Pun intended.) The goal of this post was to help you put a name to the approach you’ve chosen. And reflect on why it works (or doesn’t) for your needs. As Vincent Driessen said, "Panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself."