Update docs for primary branch rename to "main"

content/en/docs/contribute/new-content/blogs-case-studies.md

@@ -40,7 +40,7 @@ Anyone can write a blog post and submit it for review.
     - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
 - Blog posts should be original content
   - The official blog is not for repurposing existing content from a third party as new content.
-  - The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
+  - The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
 - Blog posts should aim to be future proof
   - Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader. 
   - It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post.
@@ -56,7 +56,7 @@ The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/mast
 
 To submit a blog post follow these directions:
 
-- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
+- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) directory.
 
 - Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
 
@@ -90,6 +90,6 @@ Case studies highlight how organizations are using Kubernetes to solve
 real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies.
 
 Have a look at the source for the
-[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
+[existing case studies](https://github.com/kubernetes/website/tree/main/content/en/case-studies).
 
 Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.

content/en/docs/contribute/new-content/open-a-pr.md

@@ -127,7 +127,7 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
     upstream	https://github.com/kubernetes/website.git (push)
     ```
 
-6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`:
+6. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`:
 
     ```bash
     git fetch origin
@@ -137,15 +137,15 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
     This makes sure your local repository is up to date before you start making changes.
 
     {{< note >}}
-    This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork.
+    This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `main` with `upstream/main` before pushing updates to your fork.
     {{< /note >}}
 
 ### Create a branch
 
 1. Decide which branch base to your work on:
 
-  - For improvements to existing content, use `upstream/master`.
-  - For new content about existing features, use `upstream/master`.
+  - For improvements to existing content, use `upstream/main`.
+  - For new content about existing features, use `upstream/main`.
   - For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/).
   - For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/).
   - For long-running efforts that multiple SIG Docs contributors collaborate on,
@@ -154,10 +154,10 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
 
     If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
 
-2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`:
+2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`:
 
     ```bash
-    git checkout -b <my_new_branch> upstream/master
+    git checkout -b <my_new_branch> upstream/main
     ```
 
 3.  Make your changes using a text editor.
@@ -262,7 +262,7 @@ The commands below use Docker as default container engine. Set the `CONTAINER_EN
 
 Alternately, install and use the `hugo` command on your computer:
 
-1.  Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
+1.  Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml).
 
 2.  If you have not updated your website repository, the `website/themes/docsy` directory is empty.
     The site cannot build without a local copy of the theme. To update the website theme, run:
@@ -370,11 +370,11 @@ If another contributor commits changes to the same file in another PR, it can cr
     git push --force-with-lease origin <your-branch-name>
     ```
 
-2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch:
+2. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch:
 
     ```bash
     git fetch upstream
-    git rebase upstream/master
+    git rebase upstream/main
     ```
 
 3. Inspect the results of the rebase:

content/en/docs/contribute/new-content/overview.md

@@ -42,7 +42,7 @@ When opening a pull request, you need to know in advance which branch to base yo
 
 Scenario | Branch
 :---------|:------------
-Existing or new English language content for the current release | `master`
+Existing or new English language content for the current release | `main`
 Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
 Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
 
@@ -60,6 +60,6 @@ Limit pull requests to one language per PR. If you need to make an identical cha
 
 ## Tools for contributors
 
-The [doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
+The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.