GitFlow is a structured branching model for versioned releases with staging phases. The author uses it even on solo projects to enforce discipline through protected branches, mandatory pull requests, and strict merge rules. The setup includes five branch types (main, develop, feature/*, release/*, hotfix/*),
Table of contents
2. When GitFlow Makes Sense and When It Does Not3. The GitFlow Branch Model I Actually Use on GitHub4. The Rules That Make GitFlow Work (And Why I Enforce Them on Myself)5. Pull Requests as the Core Unit of Work6. Naming, Traceability, and Future Me6. Naming, Traceability, and Future Me8. Releases, Tags, and Changelogs I Can Trust9. Environments or GitFlow Is Just Ritual10. Handling Hotfixes Without Breaking the Model11. Merge Conflicts and How I Keep Them Boring12. GitHub Actions Patterns I Reuse Everywhere13. Security and Governance I Enable by Default14. In a nutshell, what I do (copy this section)Sort: