Understanding Git Flow, Github Flow, and Gitlab Flow: Feature‑Driven Development Workflows

Git, as a source‑code management system, inevitably involves multi‑person collaboration, which requires a standardized workflow to keep projects organized and moving smoothly.

The article introduces three popular workflows: Git flow, Github flow, and Gitlab flow, all based on feature‑driven development (FDD), where requirements drive the creation of feature or hotfix branches that are merged into the main branch and then deleted.

Git flow is the earliest and most widely adopted workflow. It uses two long‑term branches— master for stable releases and develop for daily development—and three short‑term branches (feature, hotfix, release). After development, short‑term branches are merged into develop or master and deleted. Its strengths are clear control; its weaknesses are complexity and the need for two long‑term branches, which may be unnecessary for continuously deployed projects.

Github flow simplifies Git flow for continuous deployment. It has a single long‑term branch ( master ) and follows four steps: create a branch from master , open a pull request (PR), discuss and iterate on the PR, then merge the PR into master and delete the branch. It works well when the master branch always reflects the live code, but may require an additional production branch for environments where deployment lags behind merges.

Gitlab flow combines the advantages of Git flow and Github flow. It follows the “upstream first” principle, keeping only one main branch ( master ) as the upstream for all other branches. For continuous deployment, it recommends separate environment branches (e.g., pre‑production , production ) that track upstream changes. For versioned releases, stable branches (e.g., 2‑3‑stable ) are created from master for bug‑fixes only.

The article also offers practical tips: use Pull Requests (or Merge Requests) for code review, protect the master branch, manage work with Issues, prefer non‑fast‑forward merges to keep commit history clear, and squash multiple commits before opening a PR to simplify review.

Images illustrating branch structures and processes are included throughout the article.