From 3169d054aa77bd321fd1deac66daf6628756949d Mon Sep 17 00:00:00 2001
From: Jared Lockhart <119884+jaredlockhart@users.noreply.github.com>
Date: Tue, 30 Jun 2020 13:52:09 -0400
Subject: [PATCH] Rename master to main fixes #2949 (#2950)

---
 .circleci/config.yml |  6 +++---
 CODE_OF_CONDUCT.md   |  2 +-
 contributing.md      | 18 +++++++++---------
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index 40e01445f..593a6396d 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -38,7 +38,7 @@ jobs:
       - run:
           name: Build docker images
           command: |
-            cp .env.sample .env  
+            cp .env.sample .env
             make integration_build
       - run:
           name: Run integration tests
@@ -75,10 +75,10 @@ workflows:
           name: integration
           filters:
             branches:
-              ignore: master
+              ignore: main
       - deploy:
           requires:
             - build
           filters:
             branches:
-              only: master
+              only: main
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 690318ee9..5e8449eb3 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -11,5 +11,5 @@ For more information on how to report violations of the CPG, please read our '[H
 ## Contributions
 
 For all other questions about contribution see our
-[contributing.md](https://github.com/mozilla/experimenter/blob/master/contributing.md)
+[contributing.md](https://github.com/mozilla/experimenter/blob/main/contributing.md)
 document.
diff --git a/contributing.md b/contributing.md
index 8a097cbb3..19e5e2cc0 100644
--- a/contributing.md
+++ b/contributing.md
@@ -42,21 +42,21 @@ the commit with a brief description of the change and `fixes #123` where `#123`
 You can add any additional descriptive information to the message body of the commit, but the issue
 number must be present in the first line of the commit.  Example: `Add new dashboard link fixes #123`
 
-1. Push your branch up to your fork and submit a pull request on to master.  Add any additional
+1. Push your branch up to your fork and submit a pull request on to main.  Add any additional
 information you'd like to the pull request body, including descriptions of changes, screenshots
 of any UI changes, special instructions for testing, etc.
 
 1. Find a reviewer.  If you're not sure who should review, please contact us on #experimenter on
-the Mozilla Slack if you have access to it.  
+the Mozilla Slack if you have access to it.
 
-1. Any PRs that require changes to deployment infrastructure ie environment variable changes, 
+1. Any PRs that require changes to deployment infrastructure ie environment variable changes,
 dependent services, etc also require a review by a member of the operations team.  Please include
 any relevant instructions about the changes in the PR.  File a [Bugzilla ticket](https://bugzilla.mozilla.org/enter_bug.cgi?product=Data+Platform+and+Tools&component=Operations) with a link to the PR so that operations can track the change.
 
 1. If you receive feedback that requires changes to your pull request, make the changes locally,
 run `make check` again to ensure all tests and linting are passing, and then create a new commit
 that describes what feedback was addressed.  This commit can be formatted however you like, it will
-be squashed before it is merged into master.
+be squashed before it is merged into main.
 
 1. When your pull request is approved, it can be closed by using the 'Squash and Merge' button to
 squash all of the commits into a single one that refers to both the issue and the pull request and
@@ -66,7 +66,7 @@ contains any additional descriptive information.
 
 
 ## Continuous Deployment Process
-When a PR is merged into master it will automatically be deployed to the stage instance and if that
+When a PR is merged into main it will automatically be deployed to the stage instance and if that
 is successful then it will automatically be deployed to production.
 
 If the deployment fails at one of the stage/production steps, ops will automatically be paged.
@@ -74,15 +74,15 @@ If the deployment fails at one of the stage/production steps, ops will automatic
 If the deployment succeeds but the change inadvertently breaks stage/production, there are two options:
 
 * Revert the change using a revert commit
-  
-  1. Create a branch from master called `revert-#123` where `#123` is the number of the issue, and then
-  revert the commit with `git revert <squashed commit hash>`. Fix any potential conflicts or lint/test 
+
+  1. Create a branch from main called `revert-#123` where `#123` is the number of the issue, and then
+  revert the commit with `git revert <squashed commit hash>`. Fix any potential conflicts or lint/test
   failures and finish the revert commit.
 
   1. If the original PR included any database migrations, they must be preserved and reverted by creating a new
   subsequent migration
 
-    * `git checkout origin/master -- app/experimenter/experiments/migrations/XXXX_migration_file.py`
+    * `git checkout origin/main -- app/experimenter/experiments/migrations/XXXX_migration_file.py`
 
     * `make makemigrations`