Azure Repos default branch name
Many communities are considering renaming the default branch of their repository away from
master. Azure DevOps customers are no exception. We’re committed to making the renaming process as seamless as possible for project owners and contributors.
We’re joining the Git project (statement, code change) and multiple vendors including GitHub in delivering these changes. As an industry, we’re making an effort to move towards more inclusive language.
What’s changing and what’s not
- ✅ We’ve added the ability to choose the initial branch name for new repositories. If you don’t choose, you’ll get a default defined by Azure DevOps as a fall-back.
- ✅ We’ve published advice for existing repositories.
- 🚫 We’re not changing the default branch for any existing repositories. That could be highly disruptive and unexpected. You have to do this yourself (if you want to).
Each of these are discussed in detail below.
Your choice of initial branches
Beginning with this sprint’s deployment, folks with Edit policies at the project level may choose the name of the initial branch for new repositories in that project. The setting won’t change anything for existing, populated repositories. It will change the first branch created when you click New repository or when you initialize an empty repository.
(Edited!) Coming in S176, we’ll add an organization-level setting as well.
What if you don’t enable this setting?
You’ll fall through to a default defined by Azure DevOps. Today, that default is
master. Later this year, the default will switch to
We plan to make the switch in early September. Edited: we will make this switch sometime in October 2020, after the org-level setting ships.
What if I want to switch to
You don’t have to wait for us to change our default. You can turn on this feature and set
main (or whatever default you want) today.
What if I want to keep using
If you prefer not to change, you should enable this feature and set
master as your preferred branch name. Then, when the default changes to
main, your repositories will continue to use
Advice for existing repositories
Before you change existing repositories, you need to consider downstream impacts. Among those impacts are:
- Existing pull requests
- Existing clones
- Incoming links
We’ve put together guidance on changing the default branch name. It covers each of these topics in more detail and provides instructions for making the change. As we learn more (and hear feedback from you), we’ll keep that topic updated.
Should I change?
If you can, yes. This is the direction Git and the ecosystem are headed for the long term. That said, Git has defaulted to
master for a very long time. Tools and processes have sprung up which may assume the name of the default branch.
In particular, where there’s an existing repo, the disruption of changing branch names may be a large burden. Also, it can be confusing and fight muscle memory for those working in multiple repos with different default branches. Consider all the guidance and then decide whether, when, and how your organization can absorb the change.
If there’s anything we missed, or ways we could make this easier, please let us know in the comments or on Developer Community.
Been a long-time MS fan but this is very annonying, and stupid to say the least. You guys seem to be offended by literally everything 🙂
Feel free to disagree with the investment, but please be kind. There’s nothing “stupid” about offering a choice. (A lot of teams already use a different default branch, like
development, and this makes it easier for them.)
Well. It’s one thing to “offer choices”, and another to change my default and require action to be taken to keep what I always had, just because of some political correctness reasons.
At least if it is a good political correctness reason could be also a good thing.
From the point of view of inclusiveness it is a non-sense, doesn’t help to solve or mitigate any real problem, doesn’t add any value (technically, economically or morally), I also find it distracts from real problems.
Absolutely. Changes are more than welcomed if they actually do somethi.g good. This is not.
I think my problem with this change is that words mean different things in different contexts. If we were talking about renaming something like clustered servers where there are masters and slaves, I would agree, but in the context of the “master” branch, it is actually using a completely different definition. The “master” branch refers to the the master copy. If you look at the definition of the word “master”, I would argue that the definition in use here is 5b (an original from which copies can be made) and not 2f (in historical contexts : the owner of a slave). I am all for adding the feature to have a different default branch name since some teams do prefer to use a “main” or “trunk” branch, but I am opposed to breaking the world and changing the default from underneath everyone for pretty much no reason.
I’m sorry, but stupid might be an apt description. We are wasting so much time and energy trying to placate a tiny vocal minority. To most of us, the word ‘master’ in this context means ‘master copy’ and the way that it’s used technically suggests only that (unless you think that the evil master branch is oppressing all of those poor feature and bugfix branches). If you see this word used in the context of a git repo, and the first place your mind goes is to slavery, and it invokes such a reaction within you that you feel uncomfortable using the product, I’d suggest there may be something wrong with that thought process, not with the use of the word.
Again, I’m not convinced that that scenario is really happening in the minds of any significant population of people. There are real issues in the world and nonsense like this does nothing but distract.
A lot of people feel the way I do, but choose not to speak up in fear of repercussions. And when they see this type of thing happening over and over, it builds up a little bit of resentment each time. So you could even argue that it’s not just ineffective, but destructive towards the goal it’s intended to achieve.
That being said. I think choice is usually a good thing, and allowing customers to change their default branch name as they see fit is a nice feature. But changing the default for those who already have a set workflow that relies on the master branch is going to build that little bit of resentment. So after all of that, I support this feature, just don’t change the default…
Likewise, a lot of people feel differently, but choose not to speak up in fear of repercussions.
Couldn’t agree more. ‘master’ is only non inclusive in the minds of ppl who think like this. At least a new setting should be added that I can define the default name of all my new repos.
That’s what this blog post is about.
Thank you for addressing this and for creating an easy setting for any new repos going forward!
When will this begin rolling out for us to configure in our instances?
Thanks! It’s already out to something like 25% of our customers (through “Ring 2”, if you’re familiar with that terminology). It’ll continue to roll out today, tomorrow, and next week.
Yes, I am familiar with the Ring approach. I’ve heard Donovan Brown and Abel Wang mention it in many of their presentations.
Will this be a preview feature we have to enable or will it just appear in the Repo settings?
It’ll just appear. (Turned off, though, so no effect in your org.)
Incidentally, for you or anyone else awaiting a feature: you can look at the lower left of your organization landing page (go to https://dev.azure.com/ORGNAME) and see what sprint’s release notes are linked there. That’ll tell you the new goodies in whatever version you’re on.
The world has gone mad. If we have got to a point where the word ‘master’ has become offensive then seriously, what is the point? Its all about context, all about context. But hey, lets jump on that band wagon and enjoy the ride. Oh…did i say ride? Sorry to offend….yawn.
Oh FFS! Most idiotic feature that literally most of the community never even asked…
Way to bloat things with useless stuff.
Im fine with making an option to change the default but git is leaving the default to master so please don’t change the eventual default to main as it will break stuff and cause fragmentation to those who want to stay consistent.
Also, I agree that why is this being added when there are higher priority issues that have been voted on. Vscode santa hat all over again.
Thanks for this change. Those who can’t tolerate change are only a small bump in the road of progress.
can’t tolerate changes?
more like can’t tolerate changes that don’t make anything better in any meaningful way apart from satisfying someone’s ego 🙂 leave alone potentially breaking existing tools
SJWs win again, unfortunately
What are the stats? How many people were excluded previously? How many people felt prevented from being able to use AzureDevOps repos due to the lack of this feature?
I would be surprised if it was more people than are offended and feel ‘excluded’ by this sort of PC SJW nonsense.
And what about the people who find ‘main’ offensive? What about them, eh? Eh? I mean, the derivations of that word from meanings of physical force and violent effort are surely deeply offensive?!
İ don’t get it, why? What’s wrong with “master” as a default?
Scott Hanselman covers it pretty well.
Scott is a great speaker and technologist. I have to say one one of my favourites. What bothers me is what happens if we don’t change from master? What is the implication? Does that imply you are a racist? Does it mean that you are insensitive? Has this term been labelled as hate speech somewhere? Is there some petition or lobby group that asked for this to be changed? Considering the social cost of this, is this really a choice or a command.
Thanks for engaging in a constructive way. These are fair questions.
As the post indicates and I’ll emphasize again: there are real costs to changing, especially in existing repos. It’s truly a choice. This tweet frames it pretty concisely, in my opinion. Azure DevOps has several repos which we can’t change anytime soon because of this cost-benefit tradeoff. For new work, it’s zero impact on us, and we’ll leave the new
maindefault in place on Azure Repos and on GitHub. Your situation may vary.
I’m not qualified to comment on what makes up hate speech, but I’ve not personally come across anyone calling it that. I’ve mainly heard recognition that
masterprobably wasn’t chosen with negative intent. The missing link is that the word has multiple historical meanings. In Git, it’s used ambiguously enough that it can be and is taken the wrong way more often than you might think.
Ha ha. I could not see more stupid thing than this
The setting is project-wide. When I create a new project, it’s created with one default repository. How do I keep the current behavior (default master branch) for project’s default repositories and for all future projects?
The repo created in a new project is empty. If you populate it from the Azure Repos interface, it’ll be subject to whatever setting you define for the project. (If you push from a local repo, it will inherit whatever default branch that repo defines – just as Azure Repos always has.)
I’ve gone looking for a devops organizational wide setting default setting for this that will apply automatically to all new repos in all new projects created going forward but there doesn’t seem to be one. Am i missing something? Are we going to have to remember to set a default branch name for new repos for every new project that we create so that the branch name is “master”? Is this default branch name setting really only a “per project” setting?
We’ll add an organization level setting as well. The way org and project settings interact requires more thought and care, so we opted to ship the project setting quickly / first. Thanks for the feedback.
Thanks Matt – much appreciated!