Rename Git branch "master" to "main"

docs/conf.py

@@ -108,7 +108,7 @@ def django_release():
     'commit': ('https://github.com/django/django/commit/%s', ''),
     'cve': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-'),
     # A file or directory. GitHub redirects from blob to tree if needed.
-    'source': ('https://github.com/django/django/blob/master/%s', ''),
+    'source': ('https://github.com/django/django/blob/main/%s', ''),
     'ticket': ('https://code.djangoproject.com/ticket/%s', '#'),
 }
 

docs/internals/contributing/committing-code.txt

@@ -41,27 +41,27 @@ Once you're ready:
 
 .. console::
 
-    $ # Pull in the latest changes from master.
-    $ git checkout master
-    $ git pull upstream master
-    $ # Rebase the pull request on master.
+    $ # Pull in the latest changes from main.
+    $ git checkout main
+    $ git pull upstream main
+    $ # Rebase the pull request on main.
     $ git checkout pr/####
-    $ git rebase master
-    $ git checkout master
-    $ # Merge the work as "fast-forward" to master to avoid a merge commit.
+    $ git rebase main
+    $ git checkout main
+    $ # Merge the work as "fast-forward" to main to avoid a merge commit.
     $ # (in practice, you can omit "--ff-only" since you just rebased)
     $ git merge --ff-only pr/XXXX
     $ # If you're not sure if you did things correctly, check that only the
     $ # changes you expect will be pushed to upstream.
-    $ git push --dry-run upstream master
+    $ git push --dry-run upstream main
     $ # Push!
-    $ git push upstream master
+    $ git push upstream main
     $ # Delete the pull request branch.
     $ git branch -d pr/xxxx
 
-Force push to the branch after rebasing on master but before merging and
-pushing to upstream. This allows the commit hashes on master and the branch to
-match which automatically closes the pull request.
+Force push to the branch after rebasing on main but before merging and pushing
+to upstream. This allows the commit hashes on main and the branch to match
+which automatically closes the pull request.
 
 If a pull request doesn't need to be merged as multiple commits, you can use
 GitHub's "Squash and merge" button on the website. Edit the commit message as
@@ -189,7 +189,7 @@ Django's Git repository:
 
     [1.3.x] Fixed #17028 -- Changed diveintopython.org -> diveintopython.net.
 
-    Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from master.
+    Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from main.
 
   There's a `script on the wiki
   <https://code.djangoproject.com/wiki/CommitterTips#AutomatingBackports>`_

docs/internals/contributing/localizing.txt

@@ -63,7 +63,7 @@ The format files aren't managed by the use of Transifex. To change them, you
 must :doc:`create a patch<writing-code/submitting-patches>` against the
 Django source tree, as for any code change:
 
-* Create a diff against the current Git master branch.
+* Create a diff against the current Git main branch.
 
 * Open a ticket in Django's ticket system, set its ``Component`` field to
   ``Translations``, and attach the patch to it.

docs/internals/contributing/triaging-tickets.txt

@@ -420,9 +420,9 @@ inadvertent side-effect. Here's how you can determine this.
 
 Begin by writing a regression test for Django's test suite for the issue. For
 example, we'll pretend we're debugging a regression in migrations. After you've
-written the test and confirmed that it fails on the latest master, put it in a
-separate file that you can run standalone. For our example, we'll pretend we
-created ``tests/migrations/test_regression.py``, which can be run with::
+written the test and confirmed that it fails on the latest main branch, put it
+in a separate file that you can run standalone. For our example, we'll pretend
+we created ``tests/migrations/test_regression.py``, which can be run with::
 
     $ ./runtests.py migrations.test_regression
 

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -268,8 +268,8 @@ Bugs
   is applied)?
 * If it's a bug that :ref:`qualifies for a backport <supported-versions-policy>`
   to the stable version of Django, is there a release note in
-  ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the
-  master branch don't need a release note.
+  ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the main
+  branch don't need a release note.
 
 New Features
 ------------

docs/internals/contributing/writing-code/unit-tests.txt

@@ -377,8 +377,8 @@ in ``tests/auth_tests``.
 Troubleshooting
 ===============
 
-Test suite hangs or shows failures on ``master`` branch
--------------------------------------------------------
+Test suite hangs or shows failures on ``main`` branch
+-----------------------------------------------------
 
 Ensure you have the latest point release of a :ref:`supported Python version
 <faq-python-version-support>`, since there are often bugs in earlier versions

docs/internals/contributing/writing-code/working-with-git.txt

@@ -69,9 +69,9 @@ Working on a ticket
 ===================
 
 When working on a ticket, create a new branch for the work, and base that work
-on upstream/master::
+on ``upstream/main``::
 
-    git checkout -b ticket_xxxxx upstream/master
+    git checkout -b ticket_xxxxx upstream/main
 
 The -b flag creates a new branch for you locally. Don't hesitate to create new
 branches even for the smallest things - that's what they are there for.
@@ -115,7 +115,7 @@ their clone would become corrupt when you edit commits.
 
 There are also "public branches". These are branches other people are supposed
 to fork, so the history of these branches should never change. Good examples
-of public branches are the ``master`` and ``stable/A.B.x`` branches in the
+of public branches are the ``main`` and ``stable/A.B.x`` branches in the
 ``django/django`` repository.
 
 When you think your work is ready to be pulled into Django, you should create
@@ -200,7 +200,7 @@ do this, use::
   git rebase
 
 The work is automatically rebased using the branch you forked on, in the
-example case using ``upstream/master``.
+example case using ``upstream/main``.
 
 The rebase command removes all your local commits temporarily, applies the
 upstream commits, and then applies your local commits again on the work.
@@ -255,7 +255,7 @@ One of the ways that developers can contribute to Django is by reviewing
 patches. Those patches will typically exist as pull requests on GitHub and
 can be easily integrated into your local repository::
 
-    git checkout -b pull_xxxxx upstream/master
+    git checkout -b pull_xxxxx upstream/main
     curl https://github.com/django/django/pull/xxxxx.patch | git am
 
 This will create a new branch and then apply the changes from the pull request

docs/internals/git.txt

@@ -31,7 +31,7 @@ Django releases, which you can browse online.
 
 The Git repository includes several `branches`_:
 
-* ``master`` contains the main in-development code which will become
+* ``main`` contains the main in-development code which will become
   the next packaged release of Django. This is where most development
   activity is focused.
 
@@ -54,12 +54,16 @@ website can be found at `github.com/django/djangoproject.com
 .. _branches: https://github.com/django/django/branches
 .. _tags: https://github.com/django/django/tags
 
-The master branch
-=================
+The main branch
+===============
 
 If you'd like to try out the in-development code for the next release of
 Django, or if you'd like to contribute to Django by fixing bugs or developing
-new features, you'll want to get the code from the master branch.
+new features, you'll want to get the code from the main branch.
+
+.. note::
+
+   Prior to March 2021, the main branch was called ``master``.
 
 Note that this will get *all* of Django: in addition to the top-level
 ``django`` module containing Python code, you'll also get a copy of Django's
@@ -142,7 +146,7 @@ Archived feature-development work
     designed.
 
 Feature-development branches tend by their nature to be temporary. Some
-produce successful features which are merged back into Django's master to
+produce successful features which are merged back into Django's main branch to
 become part of an official release, but others do not; in either case, there
 comes a time when the branch is no longer being actively worked on by any
 developer. At this point the branch is considered closed.

docs/internals/howto-release-django.txt

@@ -135,9 +135,9 @@ any time leading up to the actual release:
    and then commit the changed man page.
 
 #. If this is the alpha release of a new series, create a new stable branch
-   from master. For example, when releasing Django 3.1::
+   from main. For example, when releasing Django 3.1::
 
-    $ git checkout -b stable/3.1.x origin/master
+    $ git checkout -b stable/3.1.x origin/main
     $ git push origin -u stable/3.1.x:stable/3.1.x
 
 #. If this is the "dot zero" release of a new series, create a new branch from

docs/internals/release-process.txt

@@ -128,10 +128,10 @@ varying levels. See `the supported versions section
 <https://www.djangoproject.com/download/#supported-versions>`_ of the download
 page for the current state of support for each version.
 
-* The current development master will get new features and bug fixes
+* The current development branch ``main`` will get new features and bug fixes
   requiring non-trivial refactoring.
 
-* Patches applied to the master branch must also be applied to the last feature
+* Patches applied to the main branch must also be applied to the last feature
   release branch, to be released in the next patch release of that feature
   series, when they fix critical problems:
 
@@ -150,8 +150,8 @@ page for the current state of support for each version.
   release for bugs that would have prevented a release in the first place
   (release blockers).
 
-* Security fixes and data loss bugs will be applied to the current master, the
-  last two feature release branches, and any other supported long-term
+* Security fixes and data loss bugs will be applied to the current main branch,
+  the last two feature release branches, and any other supported long-term
   support release branches.
 
 * Documentation fixes generally will be more freely backported to the last
@@ -162,17 +162,18 @@ page for the current state of support for each version.
 As a concrete example, consider a moment in time halfway between the release of
 Django 5.1 and 5.2. At this point in time:
 
-* Features will be added to development master, to be released as Django 5.2.
+* Features will be added to the development main branch, to be released as
+  Django 5.2.
 
 * Critical bug fixes will be applied to the ``stable/5.1.x`` branch, and
   released as 5.1.1, 5.1.2, etc.
 
 * Security fixes and bug fixes for data loss issues will be applied to
-  ``master`` and to the ``stable/5.1.x``, ``stable/5.0.x``, and
+  ``main`` and to the ``stable/5.1.x``, ``stable/5.0.x``, and
   ``stable/4.2.x`` (LTS) branches. They will trigger the release of ``5.1.1``,
   ``5.0.5``, ``4.2.8``, etc.
 
-* Documentation fixes will be applied to master, and, if easily backported, to
+* Documentation fixes will be applied to main, and, if easily backported, to
   the latest stable branch, ``5.1.x``.
 
 .. _release-process:
@@ -212,7 +213,7 @@ At the end of phase two, any unfinished features will be postponed until the
 next release.
 
 Phase two will culminate with an alpha release. At this point, the
-``stable/A.B.x`` branch will be forked from ``master``.
+``stable/A.B.x`` branch will be forked from ``main``.
 
 Phase three: bugfixes
 ~~~~~~~~~~~~~~~~~~~~~
@@ -229,7 +230,7 @@ During this phase, committers will be more and more conservative with
 backports, to avoid introducing regressions. After the release candidate, only
 release blockers and documentation fixes should be backported.
 
-In parallel to this phase, ``master`` can receive new features, to be released
+In parallel to this phase, ``main`` can receive new features, to be released
 in the ``A.B+1`` cycle.
 
 Bug-fix releases
@@ -239,7 +240,7 @@ After a feature release (e.g. A.B), the previous release will go into bugfix
 mode.
 
 The branch for the previous feature release (e.g. ``stable/A.B-1.x``) will
-include bugfixes. Critical bugs fixed on master must *also* be fixed on the
+include bugfixes. Critical bugs fixed on main must *also* be fixed on the
 bugfix branch; this means that commits need to cleanly separate bug fixes from
-feature additions. The developer who commits a fix to master will be
+feature additions. The developer who commits a fix to main will be
 responsible for also applying the fix to the current bugfix branch.

docs/internals/security.txt

@@ -46,9 +46,9 @@ Supported versions
 At any given time, the Django team provides official security support
 for several versions of Django:
 
-* The `master development branch`_, hosted on GitHub, which will become the
+* The `main development branch`_, hosted on GitHub, which will become the
   next major release of Django, receives security support. Security issues that
-  only affect the master development branch and not any stable released versions
+  only affect the main development branch and not any stable released versions
   are fixed in public without going through the :ref:`disclosure process
   <security-disclosure>`.
 
@@ -67,7 +67,7 @@ comprised solely of *supported* versions of Django: older versions may
 also be affected, but we do not investigate to determine that, and
 will not issue patches or new releases for those versions.
 
-.. _master development branch: https://github.com/django/django/
+.. _main development branch: https://github.com/django/django/
 
 .. _security-disclosure:
 

docs/intro/contributing.txt

@@ -243,12 +243,12 @@ to Django's code, the entire test suite **should** pass. If you get failures or
 errors make sure you've followed all of the previous steps properly. See
 :ref:`running-unit-tests` for more information.
 
-Note that the latest Django master may not always be stable. When developing
-against master, you can check `Django's continuous integration builds`__ to
-determine if the failures are specific to your machine or if they are also
-present in Django's official builds. If you click to view a particular build,
-you can view the "Configuration Matrix" which shows failures broken down by
-Python version and database backend.
+Note that the latest Django "main" branch may not always be stable. When
+developing against "main", you can check `Django's continuous integration
+builds`__ to determine if the failures are specific to your machine or if they
+are also present in Django's official builds. If you click to view a particular
+build, you can view the "Configuration Matrix" which shows failures broken down
+by Python version and database backend.
 
 __ https://djangoci.com
 

docs/intro/whatsnext.txt

@@ -139,7 +139,7 @@ If you're using an official release of Django, the zipped package (tarball) of
 the code includes a ``docs/`` directory, which contains all the documentation
 for that release.
 
-If you're using the development version of Django (aka the master branch), the
+If you're using the development version of Django (aka the main branch), the
 ``docs/`` directory contains all of the documentation. You can update your
 Git checkout to get the latest changes.
 
@@ -191,7 +191,7 @@ __ https://www.gnu.org/software/make/
 Differences between versions
 ============================
 
-The text documentation in the master branch of the Git repository contains the
+The text documentation in the main branch of the Git repository contains the
 "latest and greatest" changes and additions. These changes include
 documentation of new features targeted for Django's next :term:`feature
 release <Feature release>`. For that reason, it's worth pointing out our policy
@@ -200,7 +200,7 @@ to highlight recent changes and additions to Django.
 We follow this policy:
 
 * The development documentation at https://docs.djangoproject.com/en/dev/ is
-  from the master branch. These docs correspond to the latest feature release,
+  from the main branch. These docs correspond to the latest feature release,
   plus whatever features have been added/changed in the framework since then.
 
 * As we add features to Django's development version, we update the

docs/ref/contrib/gis/gdal.txt

@@ -38,8 +38,8 @@ to have some data to work with.  If you're starting out and don't yet
 have any data of your own to use, GeoDjango tests contain a number of
 data sets that you can use for testing. You can download them here::
 
-    $ wget https://raw.githubusercontent.com/django/django/master/tests/gis_tests/data/cities/cities.{shp,prj,shx,dbf}
-    $ wget https://raw.githubusercontent.com/django/django/master/tests/gis_tests/data/rasters/raster.tif
+    $ wget https://raw.githubusercontent.com/django/django/main/tests/gis_tests/data/cities/cities.{shp,prj,shx,dbf}
+    $ wget https://raw.githubusercontent.com/django/django/main/tests/gis_tests/data/rasters/raster.tif
 
 Vector Data Source Objects
 ==========================

tests/utils_tests/files/strip_tags1.html

@@ -374,7 +374,7 @@ <h1 itemscope itemtype="http://data-vocabulary.org/Breadcrumb" class="entry-titl
                 </div> <!-- /.select-menu-item -->
                 <div class="select-menu-item js-navigation-item js-navigation-target ">
                   <span class="select-menu-item-icon mini-icon mini-icon-confirm"></span>
-                  <a href="/django/django/commit/master" class="js-navigation-open select-menu-item-text js-select-button-text css-truncate-target" data-name="master" rel="nofollow" title="master">master</a>
+                  <a href="/django/django/commit/main" class="js-navigation-open select-menu-item-text js-select-button-text css-truncate-target" data-name="main" rel="nofollow" title="main">main</a>
                 </div> <!-- /.select-menu-item -->
                 <div class="select-menu-item js-navigation-item js-navigation-target ">
                   <span class="select-menu-item-icon mini-icon mini-icon-confirm"></span>