๐ Git Flow for Production Deployment (Enterprise Grade)
A complete, production-ready branching and deployment model used in enterprise environments with strict release, compliance and CI/CD requirements.
๐ Who This Is For
- Intermediate users learning structured release workflows
- Advanced engineers designing deployment pipelines
- DevOps teams managing multiโenvironment delivery
- Organizations requiring predictable, auditable release cycles
๐งฉ Core Principles
- main = production (always deployable)
- develop = integration (next release)
- feature branches = isolated work
- release branches = stabilization
- hotfix branches = urgent production fixes
- tags = immutable release points
- CI/CD automates promotion across environments
๐ณ Branch Architecture
1 2 3 4 5 6 7 | |
๐ง Branch Responsibilities
main
- Always stable
- Always deployable
- Only release merges & hotfix merges
- Protected branch (no direct commits)
develop
- Integration branch
- Contains next release
- CI runs full test suite
- Deploys automatically to dev or staging
feature/*
- Shortโlived
- Created from
develop - Merged via PR with review + CI
release/*
- Created when develop is featureโcomplete
- Used for stabilization
- Only bugfixes allowed
- Deploys to staging
- Merged into
main+ tagged - Then merged back into
develop
hotfix/*
- Created from
main - Used for urgent production fixes
- Merged into both
mainanddevelop
๐ Full Release Workflow (Enterprise)
-
Developer creates feature branch
1git checkout -b feature/login develop -
Feature branch โ PR โ review โ merge to develop
- CI: build + tests + lint
- Required approvals
-
No direct pushes
-
Release branch created
1git checkout -b release/1.4.0 develop -
Release branch deployed to staging
- Automated smoke tests
- Manual QA
- Security scans
-
Performance tests
-
Fixes applied on release branch
- Only bugfix commits allowed
-
No new features
-
Release merged into main
1 2
git checkout main git merge --no-ff release/1.4.0 -
Tag created
1 2
git tag -a v1.4.0 -m "Release 1.4.0" git push origin v1.4.0 -
CI/CD deploys tag to production
- Immutable artifact
- Rollback available
-
Audit logs stored
-
Release merged back into develop
1 2
git checkout develop git merge --no-ff main -
Release branch deleted
๐ฅ Hotfix Workflow (Enterprise)
- Critical issue detected in production
- Create hotfix branch from
main1git checkout -b hotfix/1.4.1 main - Fix โ commit โ PR โ review
- Merge into
main - Tag hotfix release
- Deploy to production
- Merge hotfix into
develop - Delete hotfix branch
๐ท๏ธ Tagging Strategy (Enterprise)
Semantic Versioning
1 | |
Examples:
v2.0.0โ breaking changesv1.5.0โ new featuresv1.4.1โ hotfix
Tag Rules
- Tags are immutable
- Tags represent production deployments
- Tags trigger production pipelines
๐งช CI/CD Integration (Enterprise)
develop branch
- Build
- Unit tests
- Integration tests
- Deploy to dev
- Optional: deploy to staging
release/* branch
- Build
- Full test suite
- Security scans
- Deploy to staging
- Manual approval gates
main branch
- Build
- Tag
- Deploy to production
- Notify stakeholders
- Generate release notes
hotfix/* branch
- Build
- Tests
- Deploy to hotfix environment
- Merge โ tag โ production deploy
๐ก๏ธ Branch Protection Rules
main
- No direct commits
- Require PR
- Require CI passing
- Require approvals
- Require signed commits
- Require linear history (optional)
develop
- No direct commits
- Require PR
- Require CI passing
release/*
- Allow only bugfix commits
- Require CI passing
๐ฆ Artifact Strategy
- Build once โ deploy everywhere
- Artifacts stored in registry (GitHub Packages, GitLab Registry, AWS ECR, Azure ACR)
- Artifacts are immutable
- Artifacts linked to tags
๐ Rollback Strategy
Rollback by tag
1 | |
Rollback by artifact
- Redeploy previous artifact
- No rebuild required
Rollback by environment snapshot
- DB snapshot
- Config snapshot
- Infrastructure snapshot
๐ Security & Compliance
- Signed commits
- Signed tags
- Protected branches
- Audit logs
- SBOM generation
- Dependency scanning
- Secret scanning
๐ค GitOps Integration
mainโ production manifestsdevelopโ staging manifests- ArgoCD / FluxCD auto-sync
- Git as the single source of truth
๐ง Best Practices
- Keep feature branches short-lived
- Automate everything
- Never rebase public branches
- Use tags for every production deployment
- Use release branches only for stabilization
- Keep
mainalways deployable