Introduction
This article outlines a robust Git branching strategy and release workflow tailored for .NET teams working with Azure DevOps. It includes clear naming conventions, branching rules, versioning practices, and release management best practices to ensure smooth development, QA, and deployment cycles.
1. Git Branch Types and Naming Conventions
Use consistent, purpose-driven branch names to make collaboration and automation easy.
| Branch |
Purpose |
Example Name |
| main |
Stable, production-ready code |
main |
| develop |
Ongoing development integration branch |
develop |
| feature/* |
New features or enhancements |
feature/user-login |
| bugfix/* |
Bug fixes during development |
bugfix/fix-api-timeout |
| release/* |
Pre-release stabilization |
release/2.3.0 |
| hotfix/* |
Urgent production fixes |
hotfix/critical-500-error |
2. Branching Decision Guide
To avoid ambiguity, use this quick reference to decide which branch to create from where:
| If You Are... |
Then Create Branch From |
| Building a new feature |
Create from develop → feature/* |
| Fixing a development bug |
Create from develop → bugfix/* |
| Preparing a release |
Create from develop → release/* |
| Fixing a critical production bug |
Create from main → hotfix/* |
3. Release Branch Workflow
Follow these steps when you're preparing a release:
1. Create a release branch from `develop`:
git checkout develop
git pull
git checkout -b release/2.3.0
git push -u origin release/2.3.0
2. Stabilize the release (bugfixes, config, version bump)
Only allow bug fixes, version updates, or release-specific config. Enforce PR policies like build success, minimum 2 reviewers, and no direct pushes.
3. Tag the release for traceability
git tag -a v2.3.0 -m "Release 2.3.0"
git push origin v2.3.0
4. Merge into main and develop
git checkout main
git merge release/2.3.0
git push
git checkout develop
git merge release/2.3.0
git push
5. (Optional) Delete the release branch
git branch -d release/2.3.0
git push origin --delete release/2.3.0
4. Hotfix Branch Workflow
For urgent production fixes:
1. Create a hotfix branch from `main`
git checkout main
git pull
git checkout -b hotfix/fix-500-error
2. Apply and commit the fix.
3. Merge into main and develop, and tag the version
git checkout main
git merge hotfix/fix-500-error
git tag -a v2.3.1 -m "Hotfix 2.3.1"
git push --follow-tags
git checkout develop
git merge hotfix/fix-500-error
git push
4. Delete the hotfix branch (optional)
git branch -d hotfix/fix-500-error
git push origin --delete hotfix/fix-500-error
5. Are Tags Preserved After Deleting a Branch?
Yes. Git tags are independent of branches and remain available even if you delete a release or hotfix branch. You can check out previous code using tags anytime.
To retrieve code from a tag:
git fetch --all --tags
git checkout tags/v2.3.0 -b fix-2.3.0
6. Best Practices Summary
| Action |
Best Practice |
| Always tag releases before deleting branches |
Ensures traceability |
| Use semantic versioning |
Helps communicate change impact |
| Automate version bumps if possible |
Reduces manual errors |
| Protect main and develop branches |
Enforce PRs, build validation |
| Use descriptive branch names |
Improves clarity and tooling |