[3.2.x] Updated Git branch "master" to "main".

This change follows a long discussion on django-develops:

https://groups.google.com/g/django-developers/c/tctDuKUGosc/

Backport of d9a266d657 from main

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