Use `main` instead of `master` as default branch name

.github/workflows/L10n-update.yml

@@ -3,7 +3,7 @@ name: L10n Update
 on:
   push:
     branches:
-      - master
+      - main
 
 jobs:
   trigger-update:

.github/workflows/docker.yml

@@ -5,7 +5,7 @@ on:
     types:
       - published
   schedule:
-    # for master, every day at midnight
+    # for main, every day at midnight
     - cron: "0 0 * * *"
   workflow_dispatch:
 

.github/workflows/php.yml

@@ -3,11 +3,11 @@ name: PHP Tests
 on:
   push:
     branches:
-      - master
+      - main
       - release/*
   pull_request:
     branches:
-      - master
+      - main
 
 jobs:
   lint:

CONTRIBUTING.md

@@ -50,7 +50,7 @@ Add a new remote `upstream` with this repository as value.
 git remote add upstream https://github.com/icinga/icingaweb2.git
 ```
 
-You can pull updates to your fork's master branch:
+You can pull updates to your fork's default branch:
 
 ```
 git fetch --all
@@ -104,15 +104,15 @@ Don't worry, you can squash those changes into a single commit later on.
 
 ## <a id="contributing-pull-requests"></a> Pull Requests
 
-Once you've committed your changes, please update your local master
+Once you've committed your changes, please update your local default
 branch and rebase your fix/feature branch against it before submitting a PR.
 
 ```
-git checkout master
+git checkout main
 git pull upstream HEAD
 
 git checkout fix/style-detail-view
-git rebase master
+git rebase main
 ```
 
 Once you've resolved any conflicts, push the branch to your remote repository.
@@ -148,22 +148,22 @@ Thanks a lot for your contribution!
 
 ### <a id="contributing-rebase"></a> Rebase a Branch
 
-If you accidentally sent in a PR which was not rebased against the upstream master,
+If you accidentally sent in a PR which was not rebased against the upstream default branch,
 developers might ask you to rebase your PR.
 
-First off, fetch and pull `upstream` master.
+First off, fetch and pull the `upstream` default branch.
 
 ```
-git checkout master
+git checkout main
 git fetch --all
 git pull upstream HEAD
 ```
 
-Then change to your working branch and start rebasing it against master:
+Then change to your working branch and start rebasing it against main:
 
 ```
 git checkout fix/style-detail-view
-git rebase master
+git rebase main
 ```
 
 If you are running into a conflict, rebase will stop and ask you to fix the problems.
@@ -196,7 +196,7 @@ If you fear to break things, do the rebase in a backup branch first and later re
 git checkout fix/style-detail-view
 git checkout -b fix/style-detail-view-rebase
 
-git rebase master
+git rebase main
 
 git branch -D fix/style-detail-view
 git checkout -b fix/style-detail-view

README.md

@@ -1,7 +1,7 @@
 # Icinga Web 2
 
 [![PHP Support](https://img.shields.io/badge/php-%3E%3D%207.2-777BB4?logo=PHP)](https://php.net/)
-![Build Status](https://github.com/icinga/icingaweb2/workflows/PHP%20Tests/badge.svg?branch=master)
+![Build Status](https://github.com/icinga/icingaweb2/workflows/PHP%20Tests/badge.svg?branch=main)
 [![Github Tag](https://img.shields.io/github/tag/Icinga/icingaweb2.svg)](https://github.com/Icinga/icingaweb2)
 
 ![Icinga Logo](https://icinga.com/wp-content/uploads/2014/06/icinga_logo.png)

RELEASE.md

@@ -25,9 +25,9 @@ Check issues at https://github.com/Icinga/icingaweb2
 
 ### Backport Commits
 
-For minor versions not branched off git master you need
-to manually backport any and all commits from the
-master branch which should be part of this release.
+For minor versions not branched off the default branch you need
+to manually backport any and all commits from it which should
+be part of this release.
 
 ### Authors
 
@@ -67,7 +67,7 @@ the [upgrading documentation](doc/80-Upgrading.md).
 git commit -v -a -m "Release version $VERSION"
 ```
 
-Create a signed tag (tags/v<VERSION>) on the `master` branch (for major
+Create a signed tag (tags/v<VERSION>) on the default branch (for major
 releases) or the `support` branch (for minor releases).
 
 ```
@@ -83,7 +83,7 @@ git push v$VERSION
 **For major releases:** Create a new `support` branch:
 
 ```
-git checkout master
+git checkout main
 git checkout -b support/2.7
 git push -u origin support/2.7
 ```
@@ -109,7 +109,7 @@ git clone git@git.icinga.com:packaging/deb-icingaweb2.git && cd deb-icingaweb2
 
 ### Branch Workflow
 
-Checkout `master` and create a new branch.
+Checkout the default and create a new branch.
 
 * For releases use x.x[.x] as branch name (e.g. 2.7 or 2.7.1)
   * `git checkout -b $VERSION`
@@ -198,7 +198,7 @@ git tag -s $VERSION-1 -m "Version $VERSION-1"
 git push origin $VERSION-1
 ```
 
-Now cherry pick the release commit to `master` so that the changes are transferred back to it.
+Now cherry pick the release commit to the default branch so that the changes are transferred back to it.
 
 **Attention**: Only the release commit. *NOT* the one switching the build type!
 

doc/01-About.md

@@ -84,7 +84,7 @@ English (en_US). However, the actual language specific files (locales) are not s
 Icinga uses a central repository to manage locales: https://github.com/Icinga/L10n
 
 If you want to provide or update a translation for your own language, please head over there where you will find
-[instructions](https://github.com/Icinga/L10n/blob/master/CONTRIBUTING.md) on how to contribute.
+[instructions](https://github.com/Icinga/L10n/blob/main/CONTRIBUTING.md) on how to contribute.
 
 ## Accessibility <a id="about-accessibility"></a>