If your repo looks like a reality show where branches fight for screen time, Gitflow can help. This guide shows how to apply the Gitflow branching model on GitHub with practical commands and pull request practices that actually keep things readable and releasable.

Initialize the branching model

Pick main as your production branch and develop as the integration branch. You can let git flow init do the polite ritual, or create the branches by hand with

git checkout -b develop
git push -u origin develop

On GitHub enable branch protection for both main and develop so nobody can push heartbreak directly. Require status checks, require reviews, and enable required CI for pull requests.

Feature branches and pull requests

Create one feature branch per task and give it a helpful name, not a cryptic rant about your day. Example names work well like feature/add-login or feature/payment-intent. Using feature branches keeps work isolated, makes code review simple, and makes rollbacks less dramatic.

• Create a branch locally with git checkout -b feature/name and push it with git push -u origin feature/name
• Open a pull request into develop and require at least one review and passing CI checks before merging
• Prefer small focused PRs, they get reviewed faster and blame is less painful when you need to bisect

Release branches and versioning

When develop is stable and ready for staging create a release branch named like release/1.2.0. Use that branch to bump version numbers, run final tests, and perform any last minute polishing. Finalize the release by merging the release branch into main and into develop so no fixes are lost.

git checkout -b release/1.2.0 develop
# bump version and test
git checkout main
git merge --no-ff release/1.2.0
git tag v1.2.0
git push origin main
git push origin --tags

Tagging the main commit with a version tag like v1.2.0 keeps your release history searchable and useful for rollbacks.

Hotfix branches for emergencies

When production breaks and someone yells your name, create a hotfix branch from main such as hotfix/1.2.1. Apply the fix, merge the hotfix into main and into develop so the fix survives in future releases, then tag and push.

git checkout -b hotfix/1.2.1 main
# fix the bug
git checkout main
git merge --no-ff hotfix/1.2.1
git tag v1.2.1
git push origin main
git push origin --tags
git checkout develop
git merge hotfix/1.2.1
git push origin develop

Best practices that do not require miracles

• Protect main and develop with required reviews and CI checks
• Name branches clearly and keep PRs small
• Use CI on pull requests to catch regressions early
• Merge hotfixes back into develop to avoid divergent history
• Keep a consistent tagging scheme like vMAJOR.MINOR.PATCH for traceable versioning

Quick checklist before you merge

• All CI checks passed
• At least one approving review
• No merge conflicts with target branch
• Version bumped if needed and tests green

Gitflow on GitHub is not a magic spell, but when paired with branch protections, CI, and sensible naming it keeps teams sane and releases predictable. Use it to bring order to your branching chaos and to avoid surprise fire drills on Friday night.