What is GitFlow?
GitFlow is a branching model that defines a set of long‑living and short‑lived branches to support parallel development, release preparation, and emergency fixes.
- Main – always production‑ready.
- Develop – integration branch for ongoing work.
- Feature/* – short‑lived branches for new functionality.
- Release/* – stabilisation branches created when a release is imminent.
- Hotfix/* – urgent fixes branched from main.
Why Use GitFlow?
The model provides clear separation of concerns, reduces risk, and creates a predictable release pipeline.
- Prevents accidental changes to production code.
- Enforces a “no new features” rule during release stabilisation.
- Creates an audit trail through explicit branch names and PR titles.
- Supports automated CI/CD gates that protect critical branches.
How to Implement GitFlow
Follow a disciplined set of rules for branch creation, protection, and merging.
- Protect main and develop branches; require status checks and approvals.
- Use pull requests as the core unit of work; never push directly to protected branches.
- Require at least one approval on every PR, even for solo developers.
- Resolve all review comments before merging.
- Enforce a single merge strategy per branch type (squash for feature, merge commit for release and hotfix).
Branch Naming Conventions
Names must convey intent and, when applicable, reference issue identifiers.
- feature/ABC-123‑description – new feature work.
- release/1.2.0 – release preparation.
- hotfix/login‑nullref – urgent production fix.
Pull Request Process
PRs act as mandatory checkpoints that capture the why, what, and how of a change.
- Template fields: Why, What, How tested, Risk, Rollback.
- Answer three core questions in the description: purpose, changes, verification.
- All conversations must be resolved before merge.
Release and Tagging Strategy
Releases are deliberate actions performed on the main branch.
- Merge release/* into main, create a tag, then merge back into develop.
- Tags exist only on main; they represent the exact code that shipped to production.
- Generate changelogs automatically from PR titles on main.
Hotfix Workflow
Hotfixes address production incidents with minimal scope.
- Branch from main, never from develop.
- Apply only the fix; no refactoring or additional changes.
- Merge back into both main and develop immediately.
Environment Setup
Three environments provide feedback loops aligned with branch purposes.
- Dev/Integration – automatically deployed from develop.
- Staging – deployed from release/* for final validation.
- Production – deployed from main; only tagged commits reach this environment.
Automation with GitHub Actions
Automation enforces rules and reduces reliance on manual discipline.
- Required status checks on protected branches act as non‑negotiable gates.
- Reusable workflows ensure consistent CI/CD across repositories.
- Environment protection rules add an approval step before production deployment.
Security and Governance
Security practices are applied even to small or side‑project repositories.
- Enable Dependabot alerts and automatic PRs for dependency updates.
- Run code scanning on every push to main, develop, and release branches.
- Grant the least privilege to workflow tokens; use OIDC where possible.