chore: rename master branch to main

.github/workflows/ci.yml

@@ -4,9 +4,9 @@ name: CI
 
 on:
   push:
-    branches: [master]
+    branches: [main]
   pull_request:
-    branches: [master]
+    branches: [main]
 
 jobs:
   documentation:

.github/workflows/linkcheck.yml

@@ -4,9 +4,9 @@ name: Linkcheck
 
 on:
   push:
-    branches: [master]
+    branches: [main]
   pull_request:
-    branches: [master]
+    branches: [main]
   workflow_dispatch:
 
 jobs:

.github/workflows/release-drafter.yml

@@ -3,7 +3,7 @@ name: Release Drafter
 on:
   push:
     branches:
-      - master
+      - main
   workflow_dispatch:
 
 jobs:

.github/workflows/requirements-pr.yml

@@ -4,7 +4,7 @@ name: Requirements (PR)
 
 on:
   pull_request:
-    branches: [master]
+    branches: [main]
 
 jobs:
   upgrade:

README.md

@@ -4,7 +4,7 @@
 [![GPLv3+ license](https://img.shields.io/badge/License-GPLv3+-blue.svg)](https://www.gnu.org/licenses/gpl-3.0-standalone.html)
 [![GitPod](https://img.shields.io/badge/Gitpod-ready--to--code-blue?logo=gitpod)](https://gitpod.io/#https://github.com/ComPWA/PWA-pages)
 <br>
-[![CI status](https://github.com/ComPWA/PWA-pages/workflows/CI/badge.svg)](https://github.com/ComPWA/PWA-pages/actions?query=branch%3Amaster+workflow%3ACI)
+[![CI status](https://github.com/ComPWA/PWA-pages/workflows/CI/badge.svg)](https://github.com/ComPWA/PWA-pages/actions?query=branch%3Amain+workflow%3ACI)
 [![pre-commit](https://img.shields.io/badge/pre--commit-enabled-brightgreen)](https://github.com/pre-commit/pre-commit)
 [![Prettier](https://camo.githubusercontent.com/687a8ae8d15f9409617d2cc5a30292a884f6813a/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f636f64655f7374796c652d70726574746965722d6666363962342e7376673f7374796c653d666c61742d737175617265)](https://prettier.io/)
 [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)

docs/develop.md

@@ -193,7 +193,7 @@ modify the dependencies. In that case, you have to rerun this command after
 pulling new commits from the repository:
 
 ```shell
-git checkout master
+git checkout main
 git pull
 pip install -r requirements-dev.txt
 ```
@@ -211,13 +211,13 @@ checks when you commit files locally (see {ref}`develop:Pre-commit`), when
 {ref}`pull request <develop:Collaboration>`.
 
 The tools are configured through files such as
-[`pyproject.toml`](https://github.com/ComPWA/PWA-pages/blob/master/pyproject.toml),
-[`.pylintrc`](https://github.com/ComPWA/PWA-pages/blob/master/.pylintrc), and
-[`tox.ini`](https://github.com/ComPWA/PWA-pages/blob/master/tox.ini), and the
+[`pyproject.toml`](https://github.com/ComPWA/PWA-pages/blob/main/pyproject.toml),
+[`.pylintrc`](https://github.com/ComPWA/PWA-pages/blob/main/.pylintrc), and
+[`tox.ini`](https://github.com/ComPWA/PWA-pages/blob/main/tox.ini), and the
 workflow files under
-[`.github`](https://github.com/ComPWA/PWA-pages/blob/master/.github). If you
-run into persistent linting errors, this may mean we need to further specify
-our conventions. In that case, it's best to
+[`.github`](https://github.com/ComPWA/PWA-pages/blob/main/.github). If you run
+into persistent linting errors, this may mean we need to further specify our
+conventions. In that case, it's best to
 {ref}`create an issue <develop:Issue management>` or a
 {ref}`pull request <develop:Collaboration>` and propose a policy change that
 can be formulated through those config files.
@@ -239,7 +239,7 @@ checks, it may take some time to initialize.
 
 Upon committing, {command}`pre-commit` now runs a set of checks as defined in
 the file
-[{file}`.pre-commit-config.yaml`](https://github.com/ComPWA/PWA-pages/blob/master/.pre-commit-config.yaml)
+[{file}`.pre-commit-config.yaml`](https://github.com/ComPWA/PWA-pages/blob/main/.pre-commit-config.yaml)
 over all staged files. You can also quickly run all checks over _all_ indexed
 files in the repository with the command:
 
@@ -501,10 +501,10 @@ look at
 
 :::
 
-The [docs](https://github.com/ComPWA/PWA-pages/tree/master/docs) folder
-contains a few Jupyter notebooks. These notebooks are run and tested whenever
-you make a {ref}`pull request <develop:Collaboration>`. If you want to improve
-those notebooks, we recommend working with
+The [docs](https://github.com/ComPWA/PWA-pages/tree/main/docs) folder contains
+a few Jupyter notebooks. These notebooks are run and tested whenever you make a
+{ref}`pull request <develop:Collaboration>`. If you want to improve those
+notebooks, we recommend working with
 [Jupyter Lab](https://jupyterlab.readthedocs.io/en/stable), which is
 {ref}`installed with the dev requirements <develop:Additional dependencies>`.
 Jupyter Lab offers a nicer developer experience than the default Jupyter
@@ -579,14 +579,14 @@ The documentation of the `stable` branch is also the default view
 {ref}`you see on Read the Docs <develop:Documentation>` (RTD). See e.g.
 [expertsystem.rtfd.io/en/stable](https://expertsystem.rtfd.io/en/stable).
 
-(master-branch)=
+(main-branch)=
 
-#### `master` branch
+#### `main` branch
 
 Represents the upcoming release of the package. This branch is not guaranteed
 to be stable, but has high {ref}`CI standards <develop:GitHub Actions>` and can
-only be updated through reviewed pull requests. The documentation of the
-`master` branch can be found on RTD under "latest", see e.g.
+only be updated through reviewed pull requests. The documentation of the `main`
+branch can be found on RTD under "latest", see e.g.
 [expertsystem.rtfd.io/en/latest](https://expertsystem.rtfd.io/en/latest).
 
 #### Epic branches
@@ -599,9 +599,9 @@ used in
 
 When working on a feature or larger refactoring that may take a longer time
 (think of implementing a new PWA formalism), we isolate its development under
-an 'epic branch', separate from the `master` branch. Eventually, this epic
-branch is to be merged back into the master, until then it is available for
-discussion and testing.
+an 'epic branch', separate from the `main` branch. Eventually, this epic branch
+is to be merged back into the `main`, until then it is available for discussion
+and testing.
 
 Pull requests to an epic branch require no code review and the CI checks are
 less strict. This allows for faster development, while still offering the
@@ -620,10 +620,10 @@ python3 -m pip install git+https://github.com/ComPWA/expertsystem@epic/some-titl
 
 #### Feature branches
 
-The {ref}`master-branch` and {ref}`develop:epic branches` can be updated
-through pull requests. It is best to create such a pull request from a separate
-branch, which does not have any CI or code review restrictions. We call this a
-"feature branch".
+The {ref}`main-branch` and {ref}`develop:epic branches` can be updated through
+pull requests. It is best to create such a pull request from a separate branch,
+which does not have any CI or code review restrictions. We call this a "feature
+branch".
 
 ### Commit conventions
 
@@ -665,7 +665,7 @@ branch, which does not have any CI or code review restrictions. We call this a
 - PRs can only be merged through 'squash and merge'. There, you will see a
   summary based on the separate commits that constitute this PR. Leave the
   relevant commits in as bullet points. See the
-  [commit history](https://github.com/ComPWA/PWA-pages/commits/master) for
+  [commit history](https://github.com/ComPWA/PWA-pages/commits/main) for
   examples. This comes in especially handy when
   {ref}`drafting a release <develop:Milestones and releases>`!
 
@@ -678,7 +678,7 @@ see for instance
 
 Release notes are
 [automatically generated from the PRs](https://github.com/release-drafter/release-drafter)
-that were merged into the master branch since the previous tag. The changelog
+that were merged into the main branch since the previous tag. The changelog
 there is generated from the PR titles and categorized by issue label. New
 releases are automatically published to PyPI when a new tag with such release
 notes is created (see

docs/software.md

@@ -16,10 +16,6 @@ maxdepth: 2
 caption: Table of contents
 ---
 software/git
-software/documentation
-software/python
-software/testing
-software/tips
 software/references
 ```
 

docs/software/git/branching.md

@@ -15,16 +15,16 @@ their own branch and you can safely bring those ideas together later on (see
 
 At core, a branch is just a label to a commit that moves on to the next if you
 {command}`git commit`. In fact, when you make your first commit after
-initializing a repository, Git automatically creates a branch called `master`.
-In {doc}`our example <commit>`, you can see this when running:
+initializing a repository, Git automatically creates a branch called `main`. In
+{doc}`our example <commit>`, you can see this when running:
 
 ```shell
 git branch
 
 ```
 
-There is a `master` branch next to the `HEAD` (which is in a "detached" state).
-The master moved along on to the second commit you made and stayed there after
+There is a `main` branch next to the `HEAD` (which is in a "detached" state).
+The main moved along on to the second commit you made and stayed there after
 you checked out the first commit. We can start a new branch from that first
 commit (the one that contains two empty files). Let's call this new branch
 `new_idea`:
@@ -37,7 +37,7 @@ git branch -v
 
 The second commands prints the existing branches along with the commits they
 point to. You'll see that there is a `new_idea` branch pointing to the first
-commit, next to the `master` branch, which is indeed pointing to the second
+commit, next to the `main` branch, which is indeed pointing to the second
 commit ("feat: add content"). The `HEAD` is still "detached", even though it
 points to the same commit as `new_idea`. To let the `HEAD` point to the new
 branch, run:
@@ -98,11 +98,11 @@ git log --graph --all --oneline
 ```
 
 This shows that there are now three commits: the initial commit, the commit to
-which the `master` branch points, and the commit to which the `new_idea` branch
+which the `main` branch points, and the commit to which the `new_idea` branch
 and the HEAD currently point. The dashes also nicely display that the
-`new_idea` branch **diverted** from the `master` branch and that the "initial
+`new_idea` branch **diverted** from the `main` branch and that the "initial
 commit" is their common parent. We can continue developing the `new_idea`
-branch while the `master` branch stays where it is:
+branch while the `main` branch stays where it is:
 
 ```shell
 mkdir folder
@@ -121,18 +121,18 @@ In this case, it noticed that {file}`file2.txt` was only moved and renamed.
 
 If we again {ref}`visualize the branching structure <visualize-branches>`, we
 see that the `new_idea` branch moved forward by one commit. When we checkout
-the `master` again, Git removes the `new_idea` versions of {file}`file1.txt`
-and {file}`file2.txt` from the working directory and unpacks the old ones from
-the `master` branch (but see the sidebar note).
+the `main` again, Git removes the `new_idea` versions of {file}`file1.txt` and
+{file}`file2.txt` from the working directory and unpacks the old ones from the
+`main` branch (but see the sidebar note).
 
 ```shell
-git checkout master
+git checkout main
 ls
 ```
 
 Let's see what happens if we
 [merge](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging)
-the `new_idea` branch _into_ the `master`:
+the `new_idea` branch _into_ the `main`:
 
 ```shell
 git merge new_idea
@@ -141,8 +141,8 @@ git merge new_idea
 Wow, what's this?? Git tells it is "removing {file}`file2.txt`", but then runs
 into a conflict for {file}`file1.txt`. Here we see that _Git does line-wise
 file comparisons_! Git noticed that the line in {file}`file1.txt` is different
-in `new_idea` than in `master`. It has indicated that difference within the
-file itself and is waiting for your input. If you have a look in the file:
+in `new_idea` than in `main`. It has indicated that difference within the file
+itself and is waiting for your input. If you have a look in the file:
 
 ```shell
 vi file1.txt
@@ -155,19 +155,19 @@ you'll see:
  this content is much better!
  =======
  some content
- >>>>>>> master
+ >>>>>>> main
 ```
 
-It shows that "some content" was the line from the `master` branch and "this
+It shows that "some content" was the line from the `main` branch and "this
 content is much better!" came in from the `HEAD` (the `HEAD` was moved to
 `new_idea`). _It's up to you what to do with this._ You can choose one of these
 two, write something entirely new, or leave it like this (not recommended, of
 course). If you think the merge is completely messed up, you can even just run
-{command}`git merge --abort` to land back safely in the untouched `master`
+{command}`git merge --abort` to land back safely in the untouched `main`
 branch!
 
-Here, let's just remove all lines but for "some content" (the `master`) and
-safe the file. Then it's a matter of staging the modified {file}`file1.txt` and
+Here, let's just remove all lines but for "some content" (the `main`) and safe
+the file. Then it's a matter of staging the modified {file}`file1.txt` and
 creating a new **merge commit**. This time, we commit the {command}`-m` message
 flag for the {command}`git commit` command. Git will launch {wiki}`Vi` with a
 pre-generated merge message. Just safe it ({command}`:x`) and Git will use it
@@ -180,9 +180,9 @@ git commit
 
 If we again {ref}`visualize the branch structure <visualize-branches>`, we see
 something cool: the "initial commit" branches off into two branches, then
-merges into a final "Merge branch 'new_idea'" commit to which the `master`
-branch has moved. The `new_idea` branch is in its old place, but we can just
-delete it now that the 'new idea' has been merged with the `master`:
+merges into a final "Merge branch 'new_idea'" commit to which the `main` branch
+has moved. The `new_idea` branch is in its old place, but we can just delete it
+now that the 'new idea' has been merged with the `main`:
 
 ```shell
 git branch -d new_idea

docs/software/git/github.md

@@ -30,7 +30,7 @@ You can name the repository with any name you wish: `upstream` is just a common
 label for the main repository.
 
 Note that the remote from which you cloned the repository is named `origin` by
-default (here: your fork). A local `master` branch is automatically checked out
+default (here: your fork). A local `main` branch is automatically checked out
 from the origin after the clone. You can list all branches with
 `git branch -a`.
 
@@ -52,8 +52,8 @@ can your contributions be added main repository through a
 - Synchronize with the changes from the main repository/upstream:
 
   - Fetch new changes: <br> `git fetch upstream`
-  - Re-apply your current branch commits to the head of the `upstream` master
-    branch: <br> `git rebase -i upstream/master`
+  - Re-apply your current branch commits to the head of the `upstream` main
+    branch: <br> `git rebase -i upstream/main`
   - At this point, conflicts between your changes and those from the main
     `upstream` repository may occur. If no conflicts appeared, then you are
     finished and you can continue coding or push your work onto you fork.
@@ -89,17 +89,17 @@ using: <br> `git push origin <local-branch-name>:<remote-branch-name>`
 Once you think your contribution is finished and can be merged into the main
 repository:
 
-- Make sure your the latest commits from the `upstream/master` are rebased onto
+- Make sure your the latest commits from the `upstream/main` are rebased onto
   your new branch and pushed to your fork
 - Log into GitHub with your account and create a PR. This is a request to merge
-  the changes in your fork branch with the `master` branch of the pycompwa or
+  the changes in your fork branch with the `main` branch of the pycompwa or
   ComPWA repository.
 - While the PR is open, commits pushed to the fork branch behind your PR will
   immediately appear in the PR.
 
 ## Commit conventions
 
-- In the master branch, it should be possible to compile and test the framework
+- In the main branch, it should be possible to compile and test the framework
   **in each commit**. In your own topic branches, it is recommended to commit
   frequently (WIP keyword), but
   [squash those commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)