Git branching strategy EASY — The GitRed flow

Part of The Big Red Button in enterprise low-code / no-code series

Git and other version control systems give software developers the power to track, manage, and organize their code.

In particular, git helps developers collaborate on code with teammates. Combining powerful features like commits and branches with specific principles and strategies helps teams organize code and reduce the time needed to manage versioning.

Git is not the same as GitHub, GitLab or Azure DevOps. In a nutshell GitHub is a cloud-based hosting service that lets you manage git repositories among other cool features. The same applies for GitLab or Azure DevOps.

So, what’s the best Git strategy for delivering your app?

Let’s start with the most complex one — Git flow.

Git flow

When it comes to Git most organizations have adopted the git flow. It is a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner. It has become something of a standard so that developers can move between projects or companies and be familiar with this standardized workflow. This flow was designed in 2010, now more than 13 years ago and has been widely adopted.

High level diagram on how this works:

Keep in mind that this would be a good process for keeping multiple production versions in the wild, in the past… think of how you would release Windows Operating System: Windows 10, cumulative updates for Windows 10, Windows 11, cumulative updates for Windows 10, new features for Windows 11 and most of us hitting the install later button on a Thursday morning :).

However, Git flow does have its issues. One of the biggest ones is that it is more complex than it would be needed for most developers and for The Big Red Button. The second one is related to speed of delivery - it is slow. The process has not been designed for automated delivery as the author explains in his note of reflection.

Do you really need a dedicated long term hotfix and release branch? You need to follow the process from command line or the web interface.

Do you really need to have a deep understanding on how all of this works? No, let’s keep it simple.

Can we reach the same level of complex scenarios for git branches? Yes, but we don’t really need the Git flow. And as a bonus we could also deliver the Windows Operating System 10 and 11 with a simpler branching strategy.

Do we want to deploy all the time? Yes.

Do we want to deploy to our end users as soon as possible? Yes

How do we deploy all the time? We would automate all of this with pipelines and move towards a Continuous Delivery process with a simple branching strategy designed for Continuous Delivery and Continuous Deployment.

GitHub flow

As a response to Git flow, the GitHub team created the simplified GitHub flow for managing development changes.

• Anything in the main branch is deployable
• To work on something new, create a descriptively named branch off of main (ie: new-oauth2-scopes)
• Commit to that branch locally and regularly push your work to the same named branch on the server
• When you need feedback or help, or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off on the feature, you can merge it into main
• Once it is merged and pushed to ‘main’, you can and should deploy immediately
• That is the entire flow.

GitHub flow assumes you can deploy to production every time you merge a feature branch. While this is possible in some cases, such as SaaS applications, there are some cases where this is not possible, such as:

• You don’t control the timing of a release. For example, you need validation on a UAT environment from key business users and you can only deploy after it passes the validation.
• You have deployment windows — for example, from 5 PM to 8 AM outside business working hours
• Your team wants to have a separate environment for staging changes before they are deployed to production.
• Your team wants to have a clear separation between the code that is in development and the code that is in production.
• Your team wants to have a more controlled release process, where only certain changes are allowed to be deployed to production at certain times.

Are there any other GitHub flow constraints that make this branching strategy not possible in your project?

GitLab flow

To overcome the GitHub flow limitations, GitLab flow designed its own strategy. Is it the right fit?

The GitLab flow can get messy if you are using multiple environments and it looks like it was designed when repetitive manual activities were still the normal way of delivering.

Let’s get the best from the existing git branching strategies.

The Big Red Button flow / The GitRed flow

Inspired from the Production branch with GitLab flow, The GitRed flow covers all scenarios in a simplified manner.

The GitRed flow comes with 2 long-term branches, main and production, and feature flag development when needed. Feature development is done using the GitHub flow (main branch) while production releases and hotfixes to production are done using the production branch.

Main branch

This is the default branch. For most purposes, the main branch is considered stable. In other words, if you check out the main branch you can expect that:

• It builds on all supported platforms/targets.
• It has beed code reviewed and qa reviewed
• All unit tests pass (as well as static tests, lint checks and the like).
• It can be published on a specific environment
• A “standard run” of the software works (e.g. if it’s a GUI application, you should be able to launch it and do most operations).

However, the main branch might not pass a comprehensive QA test at all times.

Feature branch

All development work is done in feature branches. When a new feature is being developed, a new branch is created from the main branch. This branch is used to develop the new feature in isolation from other changes. You might consider using feature toggles (feature flags) depending on your delivery use cases.

Some factors to consider when deciding whether to use feature flags when developing a new feature:

1. Project complexity: If the project is complex, with many features and components, it may benefit from the use of feature flags. Feature flags can help simplify development by allowing features to be developed and tested independently.
2. Development timeline: If the development timeline is long or uncertain, feature flags can help by allowing features to be developed and tested incrementally. This can reduce the risk of delays and ensure that the project stays on track.
3. User feedback: If user feedback is important to the project, feature flags can be used to gather feedback on new features before they are fully released. This can help ensure that new features meet user needs and expectations.
4. Team collaboration: If multiple teams are working on the same project, feature flags can help ensure that each team can work on their own features independently. This can help reduce conflicts and ensure that development progresses smoothly.
5. Maintenance and support: If the project requires ongoing maintenance and support, feature flags can help simplify the process by allowing features to be enabled or disabled as needed. This can reduce the risk of bugs and ensure that the project remains stable and reliable.

In general, any development effort that involves multiple features or components, a long or uncertain development timeline, or a need for user feedback or team collaboration could benefit from the use of feature flags. You should make sure that your product is running as expected even if the feature has been disabled.

Once the feature is complete, the feature branch is tested to ensure it is stable and meets the project’s coding and quality assurance standards.

After a successful signoff, the branch is merged back into the main branch.

Production branch

You can deploy a new version to production by merging main into the production branch. Some delivery lifecycles include a pre-production environment. If this is the case, you can deploy to the pre-production environment when doing a pull request and validate the production deployment there. The work on the main branch works just like in GitHub flow: with feature branches being merged into main.

If some features are not accepted in UAT you can disable them using feature toggles and continue without doing any complex git cherry picking.

Hotfix branch

Hotfix branches are used to fix critical bugs in the production codebase. A hotfix branch is created from the production branch and contains only the fix for the critical bug.

Once the hotfix is complete, the hotfix branch is merged into both the production branch and the release branch. This ensures that the fix is included in the current release as well as the production codebase.

Approach

Should you choose GitRed flow? Yes, for all product types and release methods except when doing Continuous Deployment. You don’t need the production branch for deployments that don’t go through manual approval stages and you should stick with GitHub flow.

Are you still doing manual deployments in enterprise app development? You should automate if you want to improve the Lead Time for Changes. You should also take some time to decide if your existing branching strategy is the right fit for automation.

Do you need to support multiple versions for your product / implementation? You can do it with GitRed flow. It’s all about pushing The Big Red button.

Is GitRed flow a good fit for you? Do you need more details? Should branching strategy be complex with multiple long-term branches? Write your feedback in the comments.

Stay tuned for more!