How to Map CI to GitFlow Branches
GitFlow uses five branch types; CI must trigger different pipelines per type, from test-only on feature branches to production deploy on main.
GitFlow separates feature/*, develop, release/*, hotfix/*, and main. Each maps to a CI intent: test on feature and develop, build a candidate on release, deploy to production on main. Use branch filters to route the right jobs.
Branch to CI mapping
| Branch | Trigger | CI intent |
|---|---|---|
| feature/* | push, PR to develop | lint + unit tests |
| develop | push | full test + deploy to staging |
| release/* | push | build release candidate + integration tests |
| hotfix/* | push | test + fast-track to production |
| main | push (merge) | deploy to production, tag release |
Workflow
.github/workflows/ci.yml
on:
push:
branches: [develop, main, 'release/**', 'hotfix/**']
pull_request:
branches: [develop]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
deploy-staging:
needs: test
if: github.ref == 'refs/heads/develop'
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh staging
deploy-prod:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh productionGotchas
- GitFlow adds ceremony; for continuous delivery, trunk-based or GitHub Flow is usually simpler.
- Keep hotfix and release branches short-lived to avoid painful merge-backs into develop.
Related guides
How to Set Up CI for Release BranchesCut a release branch, run extended integration and packaging jobs on it, and deploy the tagged build, keeping…
How to Run a Hotfix Workflow With Cherry-Pick Back to MainBranch a hotfix from main or a release tag, ship it fast through CI, then cherry-pick the fix back to develop…
How to Choose Which Branching Strategy to UseChoose between trunk-based, GitHub Flow, GitFlow, and GitLab Flow based on release cadence, environment count…