Azure-devops-docs: Tags vs. Release Branches

[AStoker]

I'm curious as to why release branches are used as opposed to tags? I would imagine making a tag on the master branch to represent a releasable state would result in less overhead than creating an entire branch for a release (that's what tags are meant for). And in the case where you need a hotfix, but you don't have everything in master ready to release (which shouldn't be a frequent case based off your model), a hotfix branch at that point could be created off the previous releasable tag, and a cherry pick of the fix could be put into that branch. This results in "release" branches only being created for the one-off hotfixes.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a7f4784d-1539-adc9-68e1-036cfc004722
• Version Independent ID: d02a6a52-e736-b411-b2f8-5be08ad3f5a0
• Content: How We Use Git at Microsoft - Azure DevOps
• Content Source: https://mseng.visualstudio.com/DefaultCollection/TechnicalContent/_git/devops-learn-pr?path=%2fdocs%2fdevops-at-microsoft%2fuse-git-microsoft.md&version=GBlive&_a=contents
• Product: devops
• Git Login: samgu
• Microsoft Alias: mattc

[steved0x]

@AStoker Sorry that it took me this long to respond to your feedback, I am engaging the product team for their feedback.

Edit: We do have some discussion here: Why not use tags for releases?

[mmitrik]

+1 to the article that @steved0x referenced.

I would imagine making a tag on the master branch to represent a releasable state would result in less overhead than creating an entire branch for a release

In Git, branches are about as lightweight as it gets - they're just a pointer to a commit. So there isn't really any overhead at all associated with creating the branch (at least from the version control point of view).

a hotfix branch at that point could be created off the previous releasable tag, and a cherry pick of the fix could be put into that branch

This is definitely a valid strategy. Really, I think it comes down to how likely you think it is that you'll create a hotfix for a release. If it's a common to hotfix a release, having the branch ready saves one extra step. As an example, every one of our releases has hotfixes, which is a function of our team size and release cadence (3 weeks). If hotfixing releases is uncommon, maybe the tag is all you need. For a team that has daily releases, I could understand why a branch per release would be overkill. There's no wrong answer here - it's all about what makes sense for your product, process, and team.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[julie-ng]

In my opinion - we should consider marking this document as "dated" to 2018. The problem is that customers assume this also means best practice, which it is not. I see it just as a story snapshot from February 2018.

Tags are better, best practice IMO…

In my non-Microsoft experience, cloud native apps/teams don't use release branches plural, maybe just one release branch and instead use tags to indicate release versions usually per semantic versioning (1.2.3 as opposed to M-129 in document's screenshot)

• tags are immutable, tied to specific commit ID whereas the head of a branch can change
• tags can be signed to indicate it was made from a trusted source
• many release branches over time create a lot of clutter and noise

Just adding this information in case others arrive here from Google searching