Git workflows for branching, tagging, and releasing vary depending on team structure, project complexity, and deployment strategy. Here are some commonly used workflows:
Branching strategies define how teams collaborate, handle feature development, and release management.
A well-defined model for large teams and projects with planned releases.
graph TD;
A[main] -->|create| B[develop]
B -->|create| C[feature/branch-name]
C -->|merge| B
B -->|create| D[release/x.y.z]
D -->|merge| A
D -->|merge| B
A -->|create| E[hotfix/x.y.z]
E -->|merge| A
E -->|merge| B
-
Main branches:
main(ormaster): Always contains stable production-ready code.develop: Integration branch for features before a release.
-
Supporting branches:
- Feature branches (
feature/branch-name): Created fromdevelopfor new features, merged back when complete. - Release branches (
release/x.y.z): Created fromdevelopwhen preparing for a release, merged intomainanddevelopafter release. - Hotfix branches (
hotfix/x.y.z): Created frommainfor urgent bug fixes, merged intomainanddevelop.
- Feature branches (
Example:
git checkout -b feature/new-feature develop
# Work on feature
git checkout develop
git merge feature/new-feature
git branch -d feature/new-featureA simpler workflow suitable for fast-moving projects and small teams.
graph TD;
A[main] -->|create| B[feature/branch-name]
B -->|pull request| A
A -->|merge| C[main]
C -->|deploy| D[production]
- Only one permanent branch (
main) - All work happens in short-lived feature branches.
- Merges are done via pull requests (PRs), often requiring approval before merging into
main.
Example:
git checkout -b feature/new-feature main
# Work on feature
git push origin feature/new-feature
# Open a PR and merge after reviewA mix of GitHub Flow and Git Flow, with structured release branches.
graph TD;
A[main] -->|create| B[feature/branch-name]
B -->|merge request| A
A -->|tag| C[release/x.y.z]
C -->|deploy| D[production]
A -->|create| E[environment/branch-name]
E -->|merge request| A
mainalways contains production-ready code.developor environment branches (staging,qa) are optional.- Feature branches are merged into
main(ordevelop). - Releases are tagged on
main.
Example:
git checkout -b feature/new-feature main
# Work, then merge via MR (merge request)
git tag v1.0.0
git push origin v1.0.0Tags mark specific commits, often for releases.
git tag v1.0.0
git push origin v1.0.0git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0git tag -d v1.0.0 # Local deletion
git push origin --delete v1.0.0 # Remote deletion- Create a
release/x.y.zbranch fromdevelop. - Stabilize it (bug fixes, testing).
- Merge into
mainand tag. - Merge back into
develop(to keep fixes).
Example:
git checkout -b release/1.0.0 develop
# Fix bugs, then finalize release
git checkout main
git merge release/1.0.0
git tag v1.0.0
git push origin v1.0.0
git checkout develop
git merge release/1.0.0- Merge features into
mainvia PRs. - Tag the commit for the new release.
Example:
git tag v1.0.0
git push origin v1.0.0- Create a
hotfix/x.y.zbranch frommain. - Fix the issue and merge back into
mainanddevelop. - Tag the release.
Example:
git checkout -b hotfix/1.0.1 main
# Fix the issue
git checkout main
git merge hotfix/1.0.1
git tag v1.0.1
git checkout develop
git merge hotfix/1.0.1- For large teams & structured releases → Git Flow.
- For fast iteration & CI/CD → GitHub Flow.
- For DevOps teams with multiple environments → GitLab Flow.