larlet-fr-david-cache/cache/2020/240b647e699da81b505d43af39257996/index.md

title: Git Branch Rename
url: https://github.com/chancancode/branch-rename/blob/main/README.md
hash_url: 240b647e699da81b505d43af39257996

<p>So, you want to rename a branch on Git/GitHub. The most common case of this is
to rename the default "master" branch to something else, such as "main". We are
going to use this as our example, but you may have a different use case in
mind. If that's the case, just replace "master" and "main" to the source and
target branches you have in mind.</p>
<h2><a id="user-content-table-of-contents" class="anchor" aria-hidden="true" href="#table-of-contents"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Table of Contents</h2>

<h2><a id="user-content-new-project" class="anchor" aria-hidden="true" href="#new-project"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>New Project</h2>
<p>If you are starting a brand new project, you can follow these steps:</p>
<ol>
<li>
<p><a href="https://github.com/new">Create a new repository on GitHub</a> to host your
project with the following settings:</p>
<ul>
<li><strong>Repository template</strong>: No template</li>
<li><strong>Initialize this repository with a README</strong>: Leave unchecked</li>
<li><strong>Add .gitignore</strong>: None</li>
<li><strong>Add a license</strong>: None</li>
</ul>
<p>If you wish to use any of these features (i.e. with settings different than
the above), that is not a problem. However, GitHub will create the default
"master" branch for you. In that case, clone the repository locally and
follow the steps in the <a href="#simple-migration"><strong>Simple Migration</strong></a> section
instead.</p>
</li>
<li>
<p>Initialize an empty Git repository:</p>
<div class="highlight highlight-source-shell"><pre>$ mkdir my-git-project
$ <span class="pl-c1">cd</span> my-git-project
$ git init <span class="pl-c1">.</span></pre></div>
</li>
<li>
<p>Create the "main" branch:</p>

</li>
<li>
<p>Work on your project and commit some changes. For example, add a README:</p>
<div class="highlight highlight-source-shell"><pre>$ <span class="pl-c1">echo</span> <span class="pl-s"><span class="pl-pds">"</span># My Git Project<span class="pl-pds">"</span></span> <span class="pl-k">&gt;&gt;</span> README.md
$ git add README.md
$ git commit -m <span class="pl-s"><span class="pl-pds">"</span>Initial commit<span class="pl-pds">"</span></span></pre></div>
</li>
<li>
<p>Push your commits to GitHub:</p>
<div class="highlight highlight-source-shell"><pre>$ git remote add origin https://github.com/your-username/my-git-project.git
$ git push -u origin main</pre></div>
</li>
</ol>
<p>That's all! Since "main" was the first branch you pushed to GitHub, it will be
set correctly as the default branch. We also never committed any changes to the
"master" branch locally, it effectively never existed so there is nothing left
to clean up. Enjoy your new project!</p>
<h2><a id="user-content-simple-migration" class="anchor" aria-hidden="true" href="#simple-migration"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Simple Migration</h2>
<p>If you have a small personal project and you are comfortable with just doing
the rename right away, here are the steps you can take.</p>
<p>Note that if this is a <a href="https://pages.github.com">GitHub Pages</a> repository and
the content is stored on the "master" branch, then you cannot perform the
migration at this time since GitHub Pages does not seem to support alternative
default branch names yet. If you want, you may follow the steps in the <a href="#local-migration"><strong>Local
Migration</strong></a> or <a href="#gradual-migration"><strong>Gradual Migration</strong></a>
section partially to get your project ready.</p>
<ol>
<li>
<p>Pull the latest commits from the "master" branch into your local repository:</p>
<div class="highlight highlight-source-shell"><pre>$ <span class="pl-c1">cd</span> my-git-project
$ git checkout master
$ git pull origin master</pre></div>
</li>
<li>
<p>Rename the local "master" branch to "main":</p>

</li>
<li>
<p>Push the "main" branch to GitHub:</p>
<div class="highlight highlight-source-shell"><pre>$ git push -u origin main</pre></div>
</li>
<li>
<p><a href="https://help.github.com/en/github/administering-a-repository/setting-the-default-branch">Change the default branch on GitHub</a> to "main".</p>
</li>
<li>
<p>If there are existing pull requests open against the "master" branch that
you would like to keep, <a href="https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request">update their base branch</a> to
the "main" branch. Otherwise, they will be closed automatically when we
delete the remote "master" branch on GitHub.</p>
</li>
<li>
<p>Delete your local "master" branch:</p>

</li>
<li>
<p>Delete the remote "master" branch:</p>
<div class="highlight highlight-source-shell"><pre>$ git push origin :master</pre></div>
</li>
</ol>
<p>At this point, the migration is complete. However, as you work on the project,
you may discover additional settings that you need to tweak to account for the
rename. For example, you may have update the branch names in your CI config.</p>
<h2><a id="user-content-gradual-migration" class="anchor" aria-hidden="true" href="#gradual-migration"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Gradual Migration</h2>
<p>If you have a work or open-source repository with multiple contributors and
forks, you may prefer to perform the migration gradually.</p>
<p>These steps are for you if you find yourself in a similar scenario, where it is
important to give everyone ample of time to prepare for the migration, changing
local configs, adapting workflows, scripts and other automation to ensure a
seamless migration.</p>
<p>This gradual migration plan is intended to be spread out over a long period of
time – weeks, or months. It uses all available tools on GitHub to provide as
much advance notice as possible.</p>
<p>For most organizations, this plan may be overly cautious and some of the steps
may not be necessary. On the other hand, for a popular open-source project, it
may not be feasible to get to the end and fully deprecate and remove the legacy
"master" branch at all, due to compatibility requirements. Treat this plan as a
template and adapt it for your own needs.</p>
<p>Unlike the other sections, the steps here are a bit less exact and is intended
for someone with a some prior experience with Git and GitHub. In practice, you
will probably run into situations that causes deviations from the plan which
would require some manual repair and adjustments. For example, pushes during a
partial GitHub outage may cause the two branches to diverge and requires you
to determine how to best reconcile the differences.</p>
<h3><a id="user-content-phase-1-mirror-master-and-main" class="anchor" aria-hidden="true" href="#phase-1-mirror-master-and-main"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Phase 1: Mirror "master" and "main"</h3>
<p>The goal of this phase is to make it <em>possible</em> to use the "main" branch name
as an alternative. This allows some early adopters to start testing the new
setup.</p>
<ol>
<li>
<p>As always, make sure your local "master" branch is up-to-date.</p>
</li>
<li>
<p>Create the new "main" branch:</p>

</li>
<li>
<p>Add a <a href="https://github.com/features/actions">GitHub Actions</a> workflow file at
<strong>.github/workflows/mirror-master-and-main.yml</strong> with the following:</p>
<div class="highlight highlight-source-yaml"><pre><span class="pl-ent">name</span>: <span class="pl-s">Mirror "master" and "main" branches</span>
<span class="pl-ent">on</span>:
  <span class="pl-ent">push</span>:
    <span class="pl-ent">branches</span>:
      - <span class="pl-s">master</span>
      - <span class="pl-s">main</span>

<span class="pl-ent">jobs</span>:
  <span class="pl-ent">mirror</span>:
    <span class="pl-ent">runs-on</span>: <span class="pl-s">ubuntu-latest</span>
    <span class="pl-ent">steps</span>:
      - <span class="pl-ent">name</span>: <span class="pl-s">Mirror to "master"</span>
        <span class="pl-ent">uses</span>: <span class="pl-s">zofrex/mirror-branch@v1</span>
        <span class="pl-ent">with</span>:
          <span class="pl-ent">target-branch</span>: <span class="pl-s">master</span>
          <span class="pl-ent">force</span>: <span class="pl-c1">false</span>
      - <span class="pl-ent">name</span>: <span class="pl-s">Mirror to "main"</span>
        <span class="pl-ent">uses</span>: <span class="pl-s">zofrex/mirror-branch@v1</span>
        <span class="pl-ent">with</span>:
          <span class="pl-ent">target-branch</span>: <span class="pl-s">main</span>
          <span class="pl-ent">force</span>: <span class="pl-c1">false</span></pre></div>
</li>
<li>
<p>Commit and your changes to the local "main" branch.</p>
</li>
<li>
<p>Push your changes to the remote "main" branch:</p>
<div class="highlight highlight-source-shell"><pre>$ git push -u origin main</pre></div>
</li>
</ol>
<p>If things are working correctly, you should see the same commit pushed to the
"master" branch shortly. You can monitor the progress and unexpected errors in
the "Actions" tab in your repository.</p>
<h4><a id="user-content-about-github-actions" class="anchor" aria-hidden="true" href="#about-github-actions"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>About GitHub Actions</h4>
<p>You do not have to be already using GitHub Actions for this to work. You do not
need to activate or enable the feature for your repository, simply pushing the
workflow file to the is sufficient. All open-source repositories have unlimited
GitHub Actions minutes, and all personal and team accounts comes with 2000-3000
free GitHub Actions minutes for private repositories.</p>
<p>If you already regularly uses up your free minutes, this may slightly increase
your GitHub bills, but in practice, the workflow we added runs very quickly so
the impact is very minimal. For reference, GitHub Actions are billed at $0.008
USD per minute for private repositories, after the free quota is exhausted.</p>
<p>This workflow will be triggered when commits are pushed to either the "master"
or "main" branch. It uses the <a href="https://github.com/marketplace/actions/mirror-branch">Mirror Branch action</a> to
update the branches using GitHub's API.</p>
<h4><a id="user-content-interaction-with-branch-protection" class="anchor" aria-hidden="true" href="#interaction-with-branch-protection"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Interaction with Branch Protection</h4>
<p>Unfortunately, if you have enabled <a href="https://help.github.com/en/github/administering-a-repository/configuring-protected-branches">branch protection</a> on
the "master" branch, the push from the mirroring action may be rejected. For
example, if you had enabled "Require pull request reviews before merging", then
this would not work as the changes are expected to be submitted via a pull
request with reviews.</p>
<p>A possible workaround is to disable the "Include administrators" checkbox in
the branch protection settings for the "master" branch and configure the script
to push the commits as an administrator:</p>
<ol>
<li>
<p>Login as an administrator on GitHub. You may also want to consider creating
a new account specifically for this purpose.</p>
</li>
<li>
<p>Generate a <a href="https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line">personal access token</a> with the "repo"
scope (and the "public_repo" scope, if needed).</p>
</li>
<li>
<p><a href="https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository">Add it as a secret</a> to the repository.</p>
</li>
<li>
<p>Change the "Checkout" step in the mirror workflow to use the new deploy key:</p>
<div class="highlight highlight-source-yaml"><pre>- <span class="pl-ent">name</span>: <span class="pl-s">Checkout</span>
  <span class="pl-ent">uses</span>: <span class="pl-s">actions/checkout@v2</span>
  <span class="pl-ent">with</span>:
    <span class="pl-ent">token</span>: <span class="pl-s">${{ secrets.DEPLOY_TOKEN }}</span></pre></div>
<p>Here, <code>DEPLOY_TOKEN</code> is the name you picked from step 3.</p>
</li>
</ol>
<p>Alternatively, an SSH key for the administrator can be used instead of a
personal access token, via the <code>ssh-key</code> argument. See the documentation for
the <a href="https://github.com/actions/checkout">checkout action</a> for more details.</p>
<h4><a id="user-content-interaction-with-other-github-action-workflows" class="anchor" aria-hidden="true" href="#interaction-with-other-github-action-workflows"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Interaction with Other GitHub Action Workflows</h4>
<p>By default, when pushing commits from within the GitHub Actions job, it does
not trigger additional GitHub Actions workflow to run. For example, when a
contributor pushes to the "main" branch, it will trigger any GitHub Actions
that normally runs on the "main" branch's push events, including the one we
added here. However, when our mirror workflow pushes the same commit to the
"master" branch, it will not trigger any workflow that normally runs on the
"master" branch's push events.</p>
<p>For this reason, you may want to update existing workflows that runs on the
"master" branch to also run on the "main" branch, as we did in our mirror
workflow file (the <code>on.push.branches</code> config key). This is the recommended
approach as it ensures only a single build per push.</p>
<p>Alternatively, if it is important to you that workflows are triggered by pushes
from the mirror workflow, you can accomplish this by supplying an alternative
SSH key to the <a href="https://github.com/actions/checkout">checkout action</a>:</p>
<ol>
<li>
<p><a href="https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent">Generate a new SSH key</a> locally. Don't worry about adding
it to the ssh-agent.</p>
</li>
<li>
<p>Find the generated <em>public key</em> and <a href="https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys">add it as a deploy key</a>
to the repository. Be sure to select "Allow write access".</p>
</li>
<li>
<p>Find the generated <em>private key</em> and <a href="https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository">add it as a secret</a> to the
repository.</p>
</li>
<li>
<p>Change the "Checkout" step in the mirror workflow to use the new deploy key:</p>
<div class="highlight highlight-source-yaml"><pre>- <span class="pl-ent">name</span>: <span class="pl-s">Checkout</span>
  <span class="pl-ent">uses</span>: <span class="pl-s">actions/checkout@v2</span>
  <span class="pl-ent">with</span>:
    <span class="pl-ent">ssh-key</span>: <span class="pl-s">${{ secrets.DEPLOY_KEY }}</span></pre></div>
<p>Here, <code>DEPLOY_KEY</code> is the name you picked from step 3.</p>
</li>
</ol>
<p>With this, the mirror workflow will authenticate with GitHub using the deploy
key instead of the default token when pushing commits, triggering any workflows
as if a regular user had pushed those commits. This does not change the author
or committer on the commits.</p>
<h4><a id="user-content-real-world-example" class="anchor" aria-hidden="true" href="#real-world-example"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Real World Example</h4>
<p>See <a href="https://github.com/chancancode/ember-concurrency-async/commit/afbacf7088e473dd056138109e00d8749b95b2d0">this commit</a> and <a href="https://github.com/chancancode/ember-concurrency-async/runs/788797792?check_suite_focus=true">the resulting workflow run</a>
for an example of this working in action. Note that the code in the commit may
be outdated by the time you read this – refer to the above for the latest
instructions.</p>
<h4><a id="user-content-next-steps" class="anchor" aria-hidden="true" href="#next-steps"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Next Steps</h4>
<p>After verifying that everything is working as intended, you can start inviting
the early adopters to start pushing to the "main" branch. The easiest way to do
this is to rename the local "master" branch:</p>
<div class="highlight highlight-source-shell"><pre>$ <span class="pl-c1">cd</span> my-git-project
$ git checkout master
$ git branch -m main
$ git branch -u origin/main</pre></div>
<p>This would also be a good time to start changing any automation or external
services to the "main" branch to ensure that everything is working as expected.</p>
<h3><a id="user-content-phase-2-change-the-default-branch-to-main-deprecate-master" class="anchor" aria-hidden="true" href="#phase-2-change-the-default-branch-to-main-deprecate-master"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Phase 2: Change the default branch to "main", deprecate "master"</h3>
<p>After verifying the viability of the rename during the previous phase, the goal
of this phase is to set "main" as the default branch and start issuing
deprecation warnings when the legacy "master" branch is used.</p>
<ol>
<li>
<p><a href="https://help.github.com/en/github/administering-a-repository/setting-the-default-branch">Change the default branch on GitHub</a> to "main".</p>
</li>
<li>
<p>Add a <a href="https://github.com/features/actions">GitHub Actions</a> workflow file at
<strong>.github/workflows/deprecate-master-branch.yml</strong> with the following:</p>
<div class="highlight highlight-source-yaml"><pre><span class="pl-ent">name</span>: <span class="pl-s">Deprecate "master" branch</span>
<span class="pl-ent">on</span>:
  <span class="pl-ent">push</span>:
    <span class="pl-ent">branches</span>:
      - <span class="pl-s">master</span>
  <span class="pl-ent">pull_request</span>:
    <span class="pl-ent">branches</span>:
      - <span class="pl-s">master</span>

<span class="pl-ent">jobs</span>:
  <span class="pl-ent">on-push</span>:
    <span class="pl-ent">runs-on</span>: <span class="pl-s">ubuntu-latest</span>
    <span class="pl-ent">if</span>: <span class="pl-s">${{ github.event_name == 'push' }}</span>
    <span class="pl-ent">steps</span>:
      - <span class="pl-ent">name</span>: <span class="pl-s">Deprecation</span>
        <span class="pl-ent">uses</span>: <span class="pl-s">peter-evans/commit-comment@v1</span>
        <span class="pl-ent">with</span>:
          <span class="pl-ent">body</span>: <span class="pl-s">|</span>
<span class="pl-s">            Hello @${{ github.event.sender.login }}!</span>
<span class="pl-s"/>
<span class="pl-s">            I see that you have pushed some commits to the "master" branch. We are in the process of renaming the "master" branch to "main" in this repository.</span>
<span class="pl-s"/>
<span class="pl-s">            :warning: **The "master" branch is deprecated and will be removed from this repository in the future.**</span>
<span class="pl-s"/>
<span class="pl-s">            Please migrate your local repository by renaming the "master" branch to "main":</span>
<span class="pl-s"/>
<span class="pl-s">            ```bash</span>
<span class="pl-s">            $ cd my-git-project</span>
<span class="pl-s">            $ git checkout master</span>
<span class="pl-s">            $ git branch -m main</span>
<span class="pl-s">            $ git branch -u origin/main</span>
<span class="pl-s">            ```</span>
<span class="pl-s"/>
<span class="pl-s">            Before merging pull requests, ensure their base branch is set to "main" instead of "master". For more information on how to do this, refer to [this GitHub support article][1].</span>
<span class="pl-s"/>
<span class="pl-s">            [1]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request</span>
<span class="pl-s"/>
<span class="pl-s"/>  <span class="pl-ent">on-pull-request</span>:
    <span class="pl-ent">runs-on</span>: <span class="pl-s">ubuntu-latest</span>
    <span class="pl-ent">if</span>: <span class="pl-s">${{ github.event_name == 'pull_request' }}</span>
    <span class="pl-ent">env</span>:
      <span class="pl-ent">DEPRECATION_MESSAGE</span>: <span class="pl-s">|</span>
<span class="pl-s">        Hello @${{ github.event.sender.login }}!</span>
<span class="pl-s"/>
<span class="pl-s">        I see that you have opened a pull request against the "master" branch. We are in the process of renaming the "master" branch to "main" in this repository.</span>
<span class="pl-s"/>
<span class="pl-s">        :warning: **The "master" branch is deprecated and will be removed from this repository in the future.**</span>
<span class="pl-s"/>
<span class="pl-s">        Please migrate your local repository by renaming the "master" branch to "main":</span>
<span class="pl-s"/>
<span class="pl-s">        ```bash</span>
<span class="pl-s">        $ cd my-git-project</span>
<span class="pl-s">        $ git checkout master</span>
<span class="pl-s">        $ git branch -m main</span>
<span class="pl-s">        $ git branch -u origin/main</span>
<span class="pl-s">        ```</span>
<span class="pl-s"/>
<span class="pl-s">        Please also set the base branch for this pull request to "main" instead of "master". For more information on how to do this, refer to [this GitHub support article][1].</span>
<span class="pl-s"/>
<span class="pl-s">        [1]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request</span>
<span class="pl-s"/>    <span class="pl-ent">steps</span>:
      - <span class="pl-ent">name</span>: <span class="pl-s">Deprecation</span>
        <span class="pl-ent">if</span>: <span class="pl-s">${{ github.event.pull_request.head.repo.fork == false }}</span>
        <span class="pl-ent">uses</span>: <span class="pl-s">peter-evans/create-or-update-comment@v1</span>
        <span class="pl-ent">with</span>:
          <span class="pl-ent">issue-number</span>: <span class="pl-s">${{ github.event.number }}</span>
          <span class="pl-ent">body</span>: <span class="pl-s">${{ env.DEPRECATION_MESSAGE }}</span>
      - <span class="pl-ent">name</span>: <span class="pl-s">Deprecation</span>
        <span class="pl-ent">if</span>: <span class="pl-s">${{ github.event.pull_request.head.repo.fork == true }}</span>
        <span class="pl-ent">run</span>: <span class="pl-s">|</span>
<span class="pl-s">         echo "$DEPRECATION_MESSAGE"</span>
<span class="pl-s">         echo '::error::Please set the base branch for this pull request to "main" instead of "master".'</span>
<span class="pl-s">         exit 1</span></pre></div>
</li>
<li>
<p>Commit and push your changes to the "main" branch.</p>
</li>
</ol>
<p>We added a workflow file that triggers whenever a contributor pushes to or
opens a pull request against the "master" branch.</p>
<p>The workflow adds a comment to the commit or pull request, notifying the
contributor that the "master" branch has been deprecated, along with the steps
they need to take to migrate their local repository and changes they need to
make it to the pull request.</p>
<p>It is recommended that you customize the messages with additional information
relevant for your organization. For example, you may want to include a link to
a tracking issue for additional context, or ways for the contributor to ask for
additional assistance if needed.</p>
<h4><a id="user-content-limitations-of-github-actions-in-forks" class="anchor" aria-hidden="true" href="#limitations-of-github-actions-in-forks"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Limitations of GitHub Actions in Forks</h4>
<p>Unfortunately, due to limitations of GitHub Actions, it is not possible to add
a pull request comment from the workflow when the pull request originated from
a fork, which is very common in open-source repositories. As a workaround, the
workflow prints the deprecation message to the logs and fails the build.</p>
<h4><a id="user-content-real-world-example-1" class="anchor" aria-hidden="true" href="#real-world-example-1"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Real World Example</h4>
<p>See <a href="https://github.com/chancancode/ember-concurrency-async/commit/7f3509b4363f3fcdb3275ec136c4b5766f39c192">this commit</a> and <a href="https://github.com/chancancode/ember-concurrency-async/pull/5">this pull request</a> for an
example of this working in action. Note that the code in the commit may be
outdated by the time you read this – refer to the above for the latest
instructions.</p>
<h4><a id="user-content-next-steps-1" class="anchor" aria-hidden="true" href="#next-steps-1"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Next Steps</h4>
<p>This would be a good time to start updating any internal and external links to
the "master" branch. A common example would be automatically generated links to
source code from the API documentation.</p>
<h3><a id="user-content-phase-3-complete-the-migration" class="anchor" aria-hidden="true" href="#phase-3-complete-the-migration"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Phase 3: Complete the migration</h3>
<p>After a successful phase 2 rollout, it is time to plan for completing the
migration. However, what completion means is going to be different depending on
your situation.</p>
<p>For private work repositories, the legacy "master" branch can likely be removed
from the repository after giving team members a few weeks to migrate. Don't
forget to remove the workflow files as well.</p>
<p>For open-source repositories with lots of contributors, you may want to move a
lot slower. Monitor the Actions tab of the repository to see how often the
deprecation workflow is triggered. When the activity diminishes, it may be good
indication that the legacy "master" branch is no longer needed.</p>
<h4><a id="user-content-soft-removal" class="anchor" aria-hidden="true" href="#soft-removal"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Soft Removal</h4>
<p>As an alternative to removing the branch right away, you may want to consider
pushing a final commit to the branch, removing all files but leave behind a
README file explaining that branch has been moved, along with the steps they
need to take in order to migrate their local repository.</p>
<h4><a id="user-content-url-considerations" class="anchor" aria-hidden="true" href="#url-considerations"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>URL Considerations</h4>
<p>It is also important to consider URL breakages, as links that points to the
files on the "master" branch will stop working once the branch is removed,
including with the soft-removal method described above.</p>
<p>The impact of this has to be evaluated contextually, but it is important to
note that the scope of the breakage is fairly limited, as this only directly
impacts URLs that links to the "master" branch directly. Links pointing to the
active development branch of repository is quite fragile (especially with line
numbers) and often breaks for other reasons.</p>
<p>For example, a refactor that moves around files or switching from JavaScript to
TypeScript would invalidate these URLs. This sort of activity is fairly common
on an active code repository and is usually performed without taking the URL
consideration in mind. For this reason, it is considered a best practice to use
SHA-based <a href="https://help.github.com/en/github/managing-files-in-a-repository/getting-permanent-links-to-files">permanent links</a> in most situations. These links
are unaffected by the branch rename.</p>
<h4><a id="user-content-packages-considerations" class="anchor" aria-hidden="true" href="#packages-considerations"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Packages Considerations</h4>
<p>For repositories containing <em>installable packages</em>, there are some additional
considerations. Many package managers allow for installing packages from a Git
repository. For example, in npm and yarn, dependencies can be a string like
"username/repo" or "username/repo#branch" in lieu of version range. Likewise,
GitHub Actions are installed using repository and branch references, and it is
a relatively common practice to point an action at the "master" branch.</p>
<p>In these cases, the decision on whether to remove the legacy "master" branch
has to be made carefully. Here are some examples of things to investigate
and consider:</p>
<ul>
<li>
<p>When the branch is omitted from the specifier (e.g. "username/repo"), does
the package manager in your ecosystem hard-code the default to "master" on
the client, or does it respect the remote HEAD ref?</p>
</li>
<li>
<p>Does the package manager use a lockfile, and if so, does it serialize the
branch name (as opposed to the resolved SHA) into the lockfile?</p>
</li>
<li>
<p>Does the package manager maintain a cache of cloned repositories, and if so
do they recover gracefully to a remote branch disappearing?</p>
</li>
</ul>
<p>The answer to these questions affects the potential impact to your end-users
if the legacy "master" branch is removed from the repository. For some, the
end-state of the migration may be to keep the "master" branch permanently as a
read-only mirror, or it may be sufficient to freeze the branch's content and
stop providing updates there. For others, the potential breakage maybe small
enough that it is can be easily justified.</p>
<p>While the workflows added in phase 2 are effective for deprecating <em>writes</em> to
the legacy "master" branch. Unfortunately, Git and GitHub do not offer the
ability to do the same for <em>reads</em> to the branch.</p>
<p>However, you may be able to use features from the package manager to accomplish
a similar result. For example, instead of mirroring the "main" branch to the
"master" branch exactly, you could add a post-install hook to the version on
"master" to issue the deprecation message for any potential consumers.</p>
<h4><a id="user-content-a-concrete-example" class="anchor" aria-hidden="true" href="#a-concrete-example"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>A Concrete Example</h4>
<p>Using the Node.js ecosystem as an example, we can put these considerations into
context, based on preliminary testing with npm and yarn classic (v1). If you
found different results in your own testing, or with other package managers
(pnpm, yarn v2, etc), please file an issue here.</p>
<ul>
<li>
<p>The popular package managers in the ecosystem support installing packages
from git, by specifying "username/repo" or "username/repo#branch" in the
dependencies section of package.json.</p>
</li>
<li>
<p>When a branch name is not specified, the popular package managers defaults to
the remote HEAD ref, which is set by the default branch on GitHub, instead of
hardcoding to the "master" branch in the client.</p>
</li>
<li>
<p>The popular package managers uses a lockfile by default. They serialize the
resolved SHA into the lockfiles, as long as the commits referred to by these
SHAs remain reachable on the remote repository, they will install just fine
when using a lockfile. In the case of a branch rename, this is not an issue,
as the history and commits will remain intact.</p>
</li>
<li>
<p>When installing without a lockfile, the popular package managers will fetch
the latest commit from the repository. Renaming the remote branch did not
appear to cause any issues, either because the repositories are not cached,
or the clients are able to recover gracefully from a "missing" remote branch.</p>
</li>
<li>
<p>Post-install hooks are supported. However, yarn classic <a href="https://github.com/yarnpkg/yarn/issues/5476">hides the output
produced by these scripts</a> if
they are successful (exit cleanly with exit code 0). However, when they fail,
they output <em>is</em> shown to the user.</p>
</li>
<li>
<p>Generally speaking, the ecosystem has strong norms and expectations around
adhering to <a href="https://semver.org" rel="nofollow">semantic versioning</a>. Usually, breaking changes are only
expected on major version bumps.</p>
</li>
<li>
<p>By using a Git dependency instead of specifying a semver range, they are
explicitly opting out of the normal semver guarantee, and breakages are to be
expected. No one could reasonably expect that pointing a dependency to the
active development branch without using a lockfile will result in a stable
system.</p>
</li>
</ul>
<p>Given these findings, here is a concrete proposal for a maximally graceful
completion plan:</p>
<ol>
<li>
<p>Stop providing updates to the "master" branch by removing the mirroring
workflow added in phase 1.</p>
</li>
<li>
<p>Push a commit the "master" branch, updating the README as well as adding a
deprecation message to the runtime code (the <code>main</code> entry point):</p>
<div class="highlight highlight-source-js"><pre><span class="pl-c">// index.js</span>

<span class="pl-k">let</span> <span class="pl-s1">command</span> <span class="pl-c1">=</span> <span class="pl-s">'npm update my-git-project'</span><span class="pl-kos">;</span>

<span class="pl-k">if</span> <span class="pl-kos">(</span><span class="pl-s1">process</span><span class="pl-kos">.</span><span class="pl-c1">env</span><span class="pl-kos">.</span><span class="pl-c1">npm_execpath</span> <span class="pl-c1">&amp;&amp;</span> <span class="pl-s1">process</span><span class="pl-kos">.</span><span class="pl-c1">env</span><span class="pl-kos">.</span><span class="pl-c1">npm_execpath</span><span class="pl-kos">.</span><span class="pl-en">indexOf</span><span class="pl-kos">(</span><span class="pl-s">'yarn'</span><span class="pl-kos">)</span> !== <span class="pl-c1">-</span><span class="pl-c1">1</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-s1">command</span> <span class="pl-c1">=</span> <span class="pl-s">'yarn upgrade my-git-project'</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>

<span class="pl-smi">console</span><span class="pl-kos">.</span><span class="pl-en">warn</span><span class="pl-kos">(</span>
  <span class="pl-s">`You are running a deprecated copy of the "my-git-project" installed `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`from the "master" branch of our repository. The "master" branch is `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`deprecated and no longer receives any updates. The branch will soon `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`be removed from our repository, at which point the package will fail `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`to install.\n\n`</span> <span class="pl-c1">+</span>
  <span class="pl-s">`To fix this issue, please modify your package.json and change the `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`"my-git-project" dependency from "my-repo/my-git-project#master" to `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`"my-repo/my-git-project" or a valid semver range. After making the `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`change, run "<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">command</span><span class="pl-kos">}</span></span>" to update the package.`</span>
<span class="pl-kos">)</span><span class="pl-kos">;</span>

<span class="pl-c">// ...rest of index.js</span></pre></div>
</li>
<li>
<p>When releasing the next major version of the package, push another commit to
the "master" branch, remove all files from the branch, leaving behind only a
minimal README file, package.json and index.js:</p>
<div class="highlight highlight-source-js"><pre><span class="pl-c">// package.json</span>
<span class="pl-kos">{</span>
  <span class="pl-s">"name"</span>: <span class="pl-s">"my-git-project"</span><span class="pl-kos">,</span>
  <span class="pl-s">"scripts"</span>: <span class="pl-kos">{</span>
    <span class="pl-s">"postinstall"</span>: <span class="pl-s">"node index.js"</span>
  <span class="pl-kos">}</span>
<span class="pl-kos">}</span></pre></div>
<div class="highlight highlight-source-js"><pre><span class="pl-c">// index.js</span>

<span class="pl-k">let</span> <span class="pl-s1">command</span> <span class="pl-c1">=</span> <span class="pl-s">'npm update my-git-project'</span><span class="pl-kos">;</span>

<span class="pl-k">if</span> <span class="pl-kos">(</span><span class="pl-s1">process</span><span class="pl-kos">.</span><span class="pl-c1">env</span><span class="pl-kos">.</span><span class="pl-c1">npm_execpath</span> <span class="pl-c1">&amp;&amp;</span> <span class="pl-s1">process</span><span class="pl-kos">.</span><span class="pl-c1">env</span><span class="pl-kos">.</span><span class="pl-c1">npm_execpath</span><span class="pl-kos">.</span><span class="pl-en">indexOf</span><span class="pl-kos">(</span><span class="pl-s">'yarn'</span><span class="pl-kos">)</span> !== <span class="pl-c1">-</span><span class="pl-c1">1</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-s1">command</span> <span class="pl-c1">=</span> <span class="pl-s">'yarn upgrade my-git-project'</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>

<span class="pl-smi">console</span><span class="pl-kos">.</span><span class="pl-en">error</span><span class="pl-kos">(</span>
  <span class="pl-s">`You have installed "my-git-project" from the "master" branch of our `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`repository. The "master" branch has been official retired.\n\n`</span> <span class="pl-c1">+</span>
  <span class="pl-s">`To fix this issue, please modify your package.json and change the `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`"my-git-project" dependency from "my-repo/my-git-project#master" to `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`"my-repo/my-git-project" or a valid semver range. After making the `</span> <span class="pl-c1">+</span>
  <span class="pl-s">`change, run "<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">command</span><span class="pl-kos">}</span></span>" to update the package.`</span>
<span class="pl-kos">)</span><span class="pl-kos">;</span>

<span class="pl-s1">process</span><span class="pl-kos">.</span><span class="pl-en">exit</span><span class="pl-kos">(</span><span class="pl-c1">1</span><span class="pl-kos">)</span><span class="pl-kos">;</span></pre></div>
</li>
<li>
<p>After some time, the master branch can be removed from the repository. This
does not constitute a breaking change, as the package already ceased to
function as of the previous commit. It was just a courteous message to ease
confusion and provide actionable instructions for fixing the issue.</p>
</li>
</ol>
<p>For most projects and organizations, this amount of notice is probably not
necessary or warranted, but it showcases the available tools and techniques,
and demonstrates that there can be a good migration path even under very strict
compatibility requirements. As always, use these steps as a template and tailor
them to your own needs.</p>
<h2><a id="user-content-local-migration" class="anchor" aria-hidden="true" href="#local-migration"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>Local Migration</h2>
<p>Finally, if you are working on a repository you don't control, and you would
like to refer to your local branch with a different name without making any
changes to the upstream project, you can rename your local "master" branch to
"main" with these steps:</p>
<div class="highlight highlight-source-shell"><pre>$ <span class="pl-c1">cd</span> my-git-project
$ git checkout master
$ git branch -m main
$ git branch -u origin/master</pre></div>
<p>This renames the local branch to "main" but sets the remote tracking branch to
"master".</p>
<h2><a id="user-content-license" class="anchor" aria-hidden="true" href="#license"><svg class="octicon octicon-link" viewbox="0 0 16 16" version="1.1" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"/></svg></a>License</h2>
<p>This content in this repository, including this documentation and code examples
are licensed under the <a href="https://creativecommons.org/share-your-work/public-domain/cc0/" rel="nofollow">CC0 "No Rights Reserved"</a> public domain
license. Feel free to reproduce and adapt this work into your own proposals,
documentation, etc.</p>
<p>Attribution is not necessary. However, this guide receives constant updates to
reflect current best-practice and solutions based implementation feedback, so
a reference to this repository may be helpful.</p>