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:
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