From Git Flow to GitLab Flow: Streamlining Your Team’s Version Control

From Git Flow to GitLab Flow

Git is the default version‑control system for most development teams, and a well‑defined workflow can make collaboration as orderly as a production pipeline.

Git Flow

Git flow is a classic branching model that separates feature, release, hot‑fix, and develop branches. While comprehensive, it often becomes overly complex in practice.

GitHub Flow

GitHub flow simplifies Git flow for continuous deployment. The process consists of:

Step 1: Create a new branch from master for a feature or fix.

Step 2: When development is ready, open a Pull Request (PR).

Step 3: Review and discuss the PR, iterating with additional commits.

Step 4: Merge the PR into master and deploy (or deploy before merging).

GitHub flow works well for libraries, frameworks, or tools, but may be unsuitable for final‑product applications that require stricter release controls.

GitHub flow is fine for libraries and frameworks, but for end‑user products a more controlled process is often needed.

GitLab Flow

GitLab flow combines the strengths of Git flow and GitHub flow. It follows an “upstream‑first” principle: a single master branch is the upstream for all other branches. Environment‑specific branches (e.g., pre‑production, production) are created off master for continuous‑deployment projects.

Only in emergencies may a change bypass the upstream and merge directly into a downstream branch.

Team Git Guidelines (Based on GitLab Flow)

At the start of an iteration, each developer creates a personal feature branch from master (e.g., feature‑name).

Finish development and merge back into master before the iteration ends.

After merging, CI/CD automatically deploys master to the dev environment.

When self‑testing passes, create a release branch release‑$version from master and deploy to the test environment.

If bugs are found, create a bug‑fix branch from the release branch, fix, then merge back into the same release branch.

Publish the version; post‑release bugs are handled using the same bug‑fix branch process.

After a stable release, merge the release branch back into master.

Feature Development Example

Create a new branch, e.g., feat‑test:

Write code and commit:

@GetMapping(path = "/test", produces = "application/json")
@ResponseBody
public Map test() {
    return singletonMap("test", "test");
}

git commit -m "feat: add test code"
git push origin feat‑test

Merge Request Process

After pushing, open a merge request (MR) to master for review.

The team lead reviews the MR, adds suggestions, and the developer updates the code accordingly.

Once approved, the MR is merged into master and the feature branch can be deleted.

Release and Semantic Versioning

Version numbers follow MAJOR.MINOR.PATCH semantics:

MAJOR : Incompatible API changes.

MINOR : Backward‑compatible feature additions.

PATCH : Backward‑compatible bug fixes.

Release branches are named release‑$version (e.g., release‑0.1) and are protected; direct pushes are forbidden, only MR merges are allowed.

CI builds the branch, producing a version string $version.$buildNumber.

Creating a release branch:

git checkout -b release-0.1

Bug‑Fix Workflow

When fixing a bug, create a branch from the relevant release‑$version, test locally, then merge back into the release branch.

Q: How to test a branch created from release‑$version?

A: Treat it as a bug‑fix branch; perform local verification before merging.

Q: What if there are too many release branches?

A: Keep the most recent ten; tag older releases and delete the branches.