Merge pull request #134 from githubtraining/rename-branch

Rename main branch in responses

Author: hectorsector

README.md

@@ -14,9 +14,9 @@ For more information on the goals of this course, check out the [`course-details
 
 ## Contribute
 
-See something we could improve? Check out the contributing guide in the [community contributors repository](https://github.com/githubtraining/community-contributors/blob/master/CONTRIBUTING.md) for more information on the types of contributions we :heart: and instructions.
+See something we could improve? Check out the contributing guide in the [community contributors repository](https://github.com/githubtraining/community-contributors/blob/main/CONTRIBUTING.md) for more information on the types of contributions we :heart: and instructions.
 
-We :heart: our community and take great care to ensure it is fun, safe and rewarding. Please review our [Code of Conduct](https://github.com/githubtraining/community-contributors/blob/master/CODE_OF_CONDUCT.md) for community expectations and guidelines for reporting concerns.
+We :heart: our community and take great care to ensure it is fun, safe and rewarding. Please review our [Code of Conduct](https://github.com/githubtraining/community-contributors/blob/main/CODE_OF_CONDUCT.md) for community expectations and guidelines for reporting concerns.
 
 ## License
 

config.yml

@@ -19,7 +19,7 @@ before:
       releases: "%payload.repository.html_url%/releases"
 
 steps:
-  #1 - ask the user to create a beta release from the most recent commit on master
+  #1 - ask the user to create a beta release from the most recent commit on main
   - title: Create a beta release
     description: Create a beta release, or a pre-release, from the existing codebase.
     event: release.published
@@ -125,13 +125,13 @@ steps:
           # We comment and let them know that they should merge
           - type: respond
             with: 05.1_early-close.md
-      # If the user does everything right, we create the next issue with instructions to create a pull request from the release branch into master
+      # If the user does everything right, we create the next issue with instructions to create a pull request from the release branch into main
       - type: createIssue
         title: Create a release pull request
         body: 05.2_release-pr.md
         action_id: releaseIssue
         data:
-          prUrl: "%payload.repository.html_url%/compare/master...release-v1.0?expand=1"
+          prUrl: "%payload.repository.html_url%/compare/main...release-v1.0?expand=1"
       # We comment in the merged pull request, and point them to the new issue with instructions
       - type: respond
         with: 05.3_response.md
@@ -141,9 +141,9 @@ steps:
       - type: closeIssue
         issue: Adding a feature
 
-  #6 - The user opens a pull request from the release branch into master
+  #6 - The user opens a pull request from the release branch into main
   - title: Open a release pull request
-    description: Create a pull request to bring the new feature into master.
+    description: Create a pull request to bring the new feature into main.
     event: pull_request
     link: "{{ repoUrl }}/issues/5"
     actions:
@@ -160,7 +160,7 @@ steps:
         gates:
           - left: "%payload.pull_request.base.ref%"
             operator: ===
-            right: master
+            right: main
           - left: "%payload.pull_request.head.ref%"
             operator: ===
             right: release-v1.0
@@ -280,9 +280,9 @@ steps:
         event: APPROVE
         pullRequest: Release v1.0
 
-  #10 - The user approves the branch merge into master
+  #10 - The user approves the branch merge into main
   - title: Merge the release branch
-    description: Merge the release branch into master.
+    description: Merge the release branch into main.
     event: pull_request.closed
     link: "{{ repoUrl }}/pull/6"
     actions:
@@ -325,7 +325,7 @@ steps:
         title: Accidental bugs
         body: 11.1_hotfix-intro.md
         head: bug-fix
-        base: master
+        base: main
         action_id: newPullRequest
       - type: assignRegistrant
         issue: "%actions.newPullRequest.data.number%"
@@ -345,7 +345,7 @@ steps:
       - type: closeIssue
         issue: Finalize the release
 
-  #12 - User resolves the bug, then approves the pull request and it is merged into master
+  #12 - User resolves the bug, then approves the pull request and it is merged into main
   - title: Approve a hotfix pull request
     description: Submit a hotfix to a previous release.
     event: pull_request_review.submitted

responses/00.1_welcome.md

@@ -1,14 +1,14 @@
 # Welcome
 
-This repository will teach you about release workflows. By the end of this course, you'll have two versions of the classic arcade game, "Alien Invasion". Let's get started! If you'd like, you can use [GitHub Pages](https://pages.github.com/) to host your Invasion game and see live updates. Go to the **Settings** tab of this repository. Scroll down to **GitHub Pages**. Select `master` as a **Source**.
+This repository will teach you about release workflows. By the end of this course, you'll have two versions of the classic arcade game, "Alien Invasion". Let's get started! If you'd like, you can use [GitHub Pages](https://pages.github.com/) to host your Invasion game and see live updates. Go to the **Settings** tab of this repository. Scroll down to **GitHub Pages**. Select `main` as a **Source**.
 
 ## The GitHub flow
 
 ![github-flow](https://user-images.githubusercontent.com/6351798/48032310-63842400-e114-11e8-8db0-06dc0504dcb5.png)
 
 The [GitHub flow](https://guides.github.com/introduction/flow/) is a lightweight, branch-based workflow for projects with regular deployments.
 
-Some projects may deploy more often, with continuous deployment. There might be a "release" every time there's a new commit on master.
+Some projects may deploy more often, with continuous deployment. There might be a "release" every time there's a new commit on main.
 
 But, some projects rely on a different structure for versions and releases.
 
@@ -31,7 +31,7 @@ Before using a release based workflow for a larger release, let's create a tag a
 1. Go to the [**Releases** page]({{ releases }}) for this repository.
     - You can click the link above, or click the **Code** tab at the top of your repository. Then, find the navigation bar below the repository description, and click **0 releases**.
 1. Click **Create a new release**.
-1. In the field for _Tag version_, specify a number. In this case, use **v0.9**. Keep the _Target_ as **master**.
+1. In the field for _Tag version_, specify a number. In this case, use **v0.9**. Keep the _Target_ as **main**.
 1. Give the release a title, like "First beta release". If you'd like, you could also give the release a short description.
 1. Select the checkbox next to **This is a pre-release**, since it is representing a beta version.
 1. Click **Publish release**.

responses/03.1_update-readme.md

@@ -2,15 +2,15 @@
 
 As you prepare for a future release, you'll need to organize more than the tasks and features. It's important to create a clear workflow for your team, and to make sure that the work remains organized.
 
-There are several strategies for managing releases. Some teams might use long-lived branches, like `production`, `dev`, and `master`. Some teams use simple feature branches, releasing from the master branch.
+There are several strategies for managing releases. Some teams might use long-lived branches, like `production`, `dev`, and `main`. Some teams use simple feature branches, releasing from the main branch.
 
 No one strategy is better than another. We always recommend being intentional about branches and reducing long-lived branches whenever possible.
 
 In this exercise, you'll use the `release-v1.0` branch to be your one long-lived branch per release version.
 
 ## Protected branches
 
-Like the `master` branch, you can protect release branches. This means you can protect branches from force pushes or accidental deletion. This is already configured in this repository.
+Like the `main` branch, you can protect release branches. This means you can protect branches from force pushes or accidental deletion. This is already configured in this repository.
 
 ## Add a feature
 

responses/05.2_release-pr.md

@@ -1,6 +1,6 @@
-## Release branches and `master`
+## Release branches and `main`
 
-You should open a pull request between your release branch and master as early as possible. It might be open for a long time, and that's okay.  The pull request corresponds to the work in the project board.
+You should open a pull request between your release branch and main as early as possible. It might be open for a long time, and that's okay.  The pull request corresponds to the work in the project board.
 
 The pull request description should:
 - Include a brief description of the pull request
@@ -11,11 +11,11 @@ To expedite the creation of this pull request, I've added a pull request templat
 
 ### Step 6: Open a release pull request
 
-Let's make a new pull request comparing the `release` branch to the `master` branch.
+Let's make a new pull request comparing the `release` branch to the `main` branch.
 
 ### :keyboard: Activity: Open a pull request
 
-1. Open a [new pull request]({{ prUrl }}) with `base: master` and `compare: release-v1.0`. 
+1. Open a [new pull request]({{ prUrl }}) with `base: main` and `compare: release-v1.0`. 
 1. Ensure the title of your pull request is **Release v1.0**
 1. Include a detailed pull request body.
 

responses/06.1_wrong-base.md

@@ -2,10 +2,10 @@ Uh oh, the branches in this pull request aren't quite right.
 
 ### :keyboard: Activity: Fix the base
 
-I was expecting `base:` set to `master`, and `compare:` set to `release-v1.0`.
+I was expecting `base:` set to `main`, and `compare:` set to `release-v1.0`.
 
 - To change just your base, see [Changing the base branch of a pull request](https://help.github.com/articles/changing-the-base-branch-of-a-pull-request/) for full instructions. 
-- To change the `compare:` branch, close this pull request and open a new one with `base:` set to `master` and `compare:` set to `release-v1.0`.
+- To change the `compare:` branch, close this pull request and open a new one with `base:` set to `main` and `compare:` set to `release-v1.0`.
 
 <hr>
 <h3 align="center">I'll respond in this pull request when you've changed the base, or in your new pull request if you close this one out.</h3>

responses/09.2_response.md

@@ -1,10 +1,10 @@
 ## Step 10: Merge the release branch
 
-Because the master branch is protected, this pull request couldn't be merged until it received an approval. I've gone ahead and approved this one for you. It looks great!
+Because the main branch is protected, this pull request couldn't be merged until it received an approval. I've gone ahead and approved this one for you. It looks great!
 
 It's generally a good idea to make sure that branches, especially long-lived ones like release branches, have the approval of your peers. Go ahead and merge before we move onto our next steps.
 
-### :keyboard: Activity: Merge into master
+### :keyboard: Activity: Merge into main
 
 1. Click **Merge pull request**.
 

responses/11.1_hotfix-intro.md

@@ -8,7 +8,7 @@ _Sometimes GitHub Pages takes a few minutes to update. Your page might not immed
 
 When bugs come up after you release a version, you'll need to address them.
 
-We've already created this branch, pull request, and suggested a fix. The suggested change will be merged into the master branch. Later we will `cherry-pick` the hotfix commits into the release branch.
+We've already created this branch, pull request, and suggested a fix. The suggested change will be merged into the main branch. Later we will `cherry-pick` the hotfix commits into the release branch.
 
 ## Step 12: Approve a hotfix pull request
 

responses/12.1_backport.md

@@ -2,7 +2,7 @@
 
 If you have previous release branches that are impacted by this bug, you might need to make a few retroactive pull requests. Generally, we do this by using [`git cherry-pick`](https://git-scm.com/docs/git-cherry-pick) to apply just those commits that should be backported.
 
-In our case, no new changes have been merged into master since we shipped our hotfix, so we can merge the entire branch as is. 
+In our case, no new changes have been merged into main since we shipped our hotfix, so we can merge the entire branch as is. 
 
 ### :keyboard: Activity: Backport the hotfix to release v1.0
 

responses/12.2_fix-merged.md

@@ -1,4 +1,4 @@
-Your fix is now on `master`! This ensures that any new code isn't based on our bug.
+Your fix is now on `main`! This ensures that any new code isn't based on our bug.
 
 Let's backport those changes to the branch with release v1.0.