Git/You understand the theory of Git workflows. Now it is time to put them into practice with real branching patterns that teams use every day. The difference between a smooth workflow and a chaotic one often comes down to how you name, create, and manage your branches.
A well-organized branching strategy is like a well-organized filing system. Anyone on the team can look at the branch list and immediately understand what is being worked on, what is ready for testing, and what is in production.
Branch naming conventions
Consistent naming is the first thing to establish. Here is the most common convention:
# Feature branches
feature/user-authentication
feature/search-bar
feature/payment-integration
# Bug fix branches
fix/login-null-pointer
fix/cart-total-calculation
# Hotfix branches (emergency production fixes)
hotfix/critical-auth-bypass
hotfix/payment-gateway-timeout
# Release branches
release/1.2.0
release/2.0.0-beta| Prefix | When to use | Created from | Merges into |
|---|---|---|---|
feature/ | New functionality | develop or main | develop or main (via PR) |
fix/ | Non-urgent bug fixes | develop or main | develop or main (via PR) |
hotfix/ | Urgent production fixes | main | main + develop |
release/ | Release preparation | develop | main + develop |
chore/ | Maintenance tasks | develop or main | develop or main (via PR) |
Good branch names are lowercase, use hyphens to separate words, and are descriptive enough that anyone can understand the purpose without opening the code.
Feature branch lifecycle
A feature branch has a clear lifecycle from creation to deletion:
# 1. Create from the latest main (or develop)
git checkout main
git pull origin main
git checkout -b feature/user-profile
# 2. Work in small commits
git add src/components/Profile.jsx
git commit -m "feat: add profile component skeleton"
git add src/api/profile.js
git commit -m "feat: add profile API endpoints"
git add tests/profile.test.js
git commit -m "test: add profile component tests"
# 3. Keep your branch up to date with main
git fetch origin
git rebase origin/main
# Resolve any conflicts
# 4. Push and create a pull request
git push -u origin feature/user-profile
# 5. After PR approval and merge, delete the branch
git checkout main
git pull
git branch -d feature/user-profile
git push origin --delete feature/user-profileThe short-lived branch rule
Feature branches should live for days, not weeks. Long-lived branches accumulate merge conflicts and become increasingly difficult to review.
| Branch age | Conflict risk | Review difficulty | Recommendation |
|---|---|---|---|
| 1-3 days | Low | Easy | Ideal |
| 1 week | Medium | Manageable | Acceptable |
| 2+ weeks | High | Painful | Split into smaller branches |
| 1+ month | Very high | Nearly impossible | Refactor your approach |
If a feature takes more than a week, break it into smaller incremental PRs that can be merged independently.
Hotfix workflow
When production is down, you need a fast path to deploy a fix without waiting for the normal release process.
# 1. Create hotfix branch from main (production)
git checkout main
git pull
git checkout -b hotfix/critical-auth-fix
# 2. Fix the bug with minimal changes
git add src/auth.js
git commit -m "fix: prevent null pointer in session check"
# 3. Push and create an expedited PR
git push -u origin hotfix/critical-auth-fix
# PR review is faster for hotfixes, but still required
# 4. After merge to main, also merge into develop
git checkout develop
git merge main
git pushThe key principle: hotfixes touch production code, so they must be small, focused, and reviewed. The review can be expedited (one reviewer instead of two), but never skipped entirely.
Release branch workflow
For teams using Git Flow, release branches provide a staging areaWhat is staging area?A holding zone in Git where you place changes you want to include in your next commit, letting you select exactly which modifications to save. between development and production:
# 1. Create release branch from develop
git checkout develop
git checkout -b release/1.2.0
# 2. Only bug fixes allowed on release branches
git commit -m "fix: correct date format in reports"
git commit -m "fix: handle empty cart edge case"
# 3. When ready, merge to main and tag
git checkout main
git merge release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin main --tags
# 4. Merge back to develop so fixes are not lost
git checkout develop
git merge release/1.2.0
git push
# 5. Delete the release branch
git branch -d release/1.2.0Cleaning up old branches
Stale branches clutter your repositoryWhat is repository?A project folder tracked by Git that stores your files along with the complete history of every change, inside a hidden .git directory.. Regularly clean up merged branches:
# List branches that have been merged into main
git branch --merged main
# Delete them locally
git branch -d feature/old-feature
# Delete them on the remote
git push origin --delete feature/old-feature
# Prune remote tracking references
git fetch --pruneQuick reference
| Task | Command |
|---|---|
| Create feature branch | git checkout -b feature/name |
| Keep branch updated | git fetch origin && git rebase origin/main |
| Create hotfix | git checkout main && git checkout -b hotfix/name |
| Create release | git checkout develop && git checkout -b release/x.y.z |
| Tag a release | git tag -a v1.2.0 -m "Release 1.2.0" |
| Delete merged branch | git branch -d branch-name |
| Delete remote branch | git push origin --delete branch-name |
| Clean stale references | git fetch --prune |