[skip netlify] updates to guides

contributing_to_docs/contributing.adoc

@@ -123,6 +123,9 @@ only some OpenShift distributions, specify them in the `_topic_map.yml`
 file.
 
 == Release branches
+
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 With the combination of conditionalizing content within files with
 `ifdef/endif` and conditionalizing whole files in the `_topic_map.yml`
 file, the `master` branch of

contributing_to_docs/create_or_edit_content.adoc

@@ -24,6 +24,8 @@ your local source branch is in sync with the remote and that you have all the
 latest changes. You must also ensure that your forked repository is also in sync
 with the remote repository.
 
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 [NOTE]
 ====
 Because most changes in this repository must be committed to the `master`
@@ -116,6 +118,8 @@ $ git commit -am "Detailed comments about what changes were made; for example, f
 
 *Step 5:* Rebase updates from `master` into your working branch
 
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 Remember that you must rebase against the branch that you created this working
 branch from. In most cases, it will be the master branch for the 4.x stream.
 
@@ -139,6 +143,9 @@ $ git push origin <working_branch>
 ----
 
 == Submit PR to merge your work
+
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 When you have pushed your changes to your GitHub account, you can submit a PR to
 have your work from your GitHub fork to the `master` branch of the OpenShift
 documentation repository. The documentation team will review the work, advise of
@@ -151,10 +158,13 @@ your local branch that includes all of your work.
 3. If you know which product versions your change applies to, include a comment
 that specifies the minimum version that the change applies to. The docs team
 maintains these branches for all active and future distros and your PR will be
-applied to one or more of these branches. 
+applied to one or more of these branches.
 4. Tag the documentation team with @openshift/team-documentation (if you are a part of the OpenShift organization. If not, tag @vikram-redhat).
 
 == Confirm your changes have been merged
+
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 When your PR has been merged into the `master` branch, you should confirm and
 then sync your local and GitHub repositories with the `master` branch.
 
@@ -212,6 +222,9 @@ everything with the local copy. You should now see the new commits in the
 existing PR. Sometimes a refresh of your browser may be required.
 
 == Delete the local working branch
+
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 When you have confirmed that all of your changes have been accepted and merged,
 and you have pulled the latest changes on `master` and pushed them to your
 GitHub account, you can delete the local working branch. Ensure you are in your

contributing_to_docs/tools_and_setup.adoc

@@ -137,6 +137,9 @@ some basic guidelines to keep things consistent across our content.
 workstation to edit existing content or create content.
 
 === How to deploy to your own OpenShift cluster for testing
+
+> **NOTE**: The OpenShift docs team will rename the master branch to the main branch at 4.8 GA.
+
 You can deploy to your own OpenShift cluster for development. This process will use your github repo to launch the website,
 and therefore your github repo must have all of the upstream branches. `master` is used for site changes,
 so assuming all your work is in `master`, you can remove all remote branches and then push the upstream branches.