Gitflow vs Gitlab Flow

Choosing the right Git branching strategy can have a significant impact on your team’s productivity and release process. In this post, we’ll compare two popular approaches — Gitflow and Gitlab Flow — and explain why we adopted Gitlab Flow at Vectorwyse.

What is Gitflow?

Gitflow primarily relies on two long-lived branches: master and develop.

Source: A successful Git branching model

Here’s how it works:

1. Developers work from the develop branch, creating feature branches that merge back into develop upon completion.
2. When a release is ready, the develop branch gets promoted to master and tagged as production-ready.
3. Hotfixes require creating branches from master, then merging fixes into both master and develop.

The hotfix process is where things get tricky. Because you’re merging into two branches, you’re more likely to encounter merge conflicts — especially if develop has diverged significantly from master.

What is Gitlab Flow?

Gitlab Flow streamlines the process by using a single main branch called master.

Source: GitLab Flow

Here’s the workflow:

1. Developers work directly from master, creating and merging feature branches as needed.
2. When a release is ready, a release branch is created from master, tagged, and released.
3. Production bug fixes follow the standard workflow — fix on master first, then cherry-pick the change into the release branch.

Cherry-picking has a much lower conflict potential than Gitflow’s approach of merging hotfixes into two diverging branches.

Why We Chose Gitlab Flow

We adopted Gitlab Flow at Vectorwyse because of its simplicity. The model allows developers to work normally on master while delegating release management to a dedicated release engineer — someone who doesn’t need deep code knowledge to manage the process.

Release Process

1. Create a release branch from master (e.g., v1.0)
2. Tag the branch (e.g., v1.0.1)
3. Release the tagged version

Bug Fix Process

1. Developer merges the fix into master, noting the revision number
2. Release engineer cherry-picks the revision into the release branch
3. Tags as a new version (e.g., v1.0.2)
4. Releases the tagged version

Conclusion

Both strategies have their merits, but for teams that value simplicity and a clean release process, Gitlab Flow is an excellent choice. It reduces merge conflicts, simplifies hotfix workflows, and separates day-to-day development from release management.