Przejdลบ do treล›ci

๐Ÿš€ 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
main
โ”‚
โ”œโ”€โ”€ hotfix/*
โ”‚
โ””โ”€โ”€ develop
    โ”œโ”€โ”€ feature/*
    โ””โ”€โ”€ release/*

๐Ÿ”ง 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 main and develop

๐Ÿš€ Full Release Workflow (Enterprise)

  1. Developer creates feature branch

    1
    git checkout -b feature/login develop
    

  2. Feature branch โ†’ PR โ†’ review โ†’ merge to develop

  3. CI: build + tests + lint
  4. Required approvals
  5. No direct pushes

  6. Release branch created

    1
    git checkout -b release/1.4.0 develop
    

  7. Release branch deployed to staging

  8. Automated smoke tests
  9. Manual QA
  10. Security scans
  11. Performance tests

  12. Fixes applied on release branch

  13. Only bugfix commits allowed
  14. No new features

  15. Release merged into main

    1
    2
    git checkout main
    git merge --no-ff release/1.4.0
    

  16. Tag created

    1
    2
    git tag -a v1.4.0 -m "Release 1.4.0"
    git push origin v1.4.0
    

  17. CI/CD deploys tag to production

  18. Immutable artifact
  19. Rollback available
  20. Audit logs stored

  21. Release merged back into develop

    1
    2
    git checkout develop
    git merge --no-ff main
    

  22. Release branch deleted


๐Ÿ”ฅ Hotfix Workflow (Enterprise)

  1. Critical issue detected in production
  2. Create hotfix branch from main
    1
    git checkout -b hotfix/1.4.1 main
    
  3. Fix โ†’ commit โ†’ PR โ†’ review
  4. Merge into main
  5. Tag hotfix release
  6. Deploy to production
  7. Merge hotfix into develop
  8. Delete hotfix branch

๐Ÿท๏ธ Tagging Strategy (Enterprise)

Semantic Versioning

1
MAJOR.MINOR.PATCH

Examples:

  • v2.0.0 โ€” breaking changes
  • v1.5.0 โ€” new features
  • v1.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
git checkout v1.4.0

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 manifests
  • develop โ†’ 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 main always deployable