GitHub Workflow (Branching Model)

Branch strategy for mobile teams

Mobile apps need predictable branches because store binaries map to specific commits. GitFlow-lite (main + develop + feature + release + hotfix) works well for teams with scheduled releases.

Branch definitions

• main — always deployable; protected; requires PR + all status checks + 1 approval.
• develop — integration branch; auto-deploys to staging on every merge.
• feature/JIRA-123-login — one ticket per branch; max 3–5 days lifespan; squash merge.
• release/2.4.0 — cut from develop when feature freeze; only bugfixes allowed.
• hotfix/crash-on-launch — branch from main tag; PATCH version bump; merge to main AND develop.

git checkout develop && git pull
git checkout -b release/2.4.0
# bump version in app.json, update CHANGELOG.md
git commit -am "chore: prepare release 2.4.0"
git push -u origin release/2.4.0
# after QA approval:
git checkout main && git merge release/2.4.0
git tag v2.4.0 && git push origin main --tags
git checkout develop && git merge release/2.4.0

Hotfix workflow (urgent production fix)

• Branch hotfix/2.4.1 from main at the current production tag.
• Fix, test, bump PATCH version, merge to main, tag v2.4.1, trigger release pipeline.
• Cherry-pick or merge hotfix back to develop so the fix is not lost in next release.
• Document in post-mortem: root cause, test added, rollout percentage when issue detected.