chore: Update references of master to main (cloudevents#316)

lholmquist · web-flow · commit 4bf2eb838a32 · 2020-08-12T19:00:02.000-04:00
Signed-off-by: Lucas Holmquist &lt;lholmqui@redhat.com&gt;
diff --git a/.github/pull-request-template.md b/.github/pull-request-template.md
@@ -1,12 +1,12 @@
 <!-- General PR guidelines:
 
-Most PRs should be opened against the master branch.
+Most PRs should be opened against the main branch.
 
  -->
 
 ## Proposed Changes
 
-- 
+-
 -
 -
 
diff --git a/.github/workflows/nodejs-ci-action.yml b/.github/workflows/nodejs-ci-action.yml
@@ -5,9 +5,9 @@ name: Node.js CI
 
 on:
   push:
-    branches: [ master ]
+    branches: [ main ]
   pull_request:
-    branches: [ master ]
+    branches: [ main ]
 
 jobs:
   build:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -38,4 +38,4 @@ check your code style for linting errors without running tests, you can just
 run `npm run lint`. If there are errors, you can usually fix them automatically
 by running `npm run fix`.
 
-Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/master/.eslintrc).
+Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/main/.eslintrc).
diff --git a/README.md b/README.md
@@ -110,7 +110,7 @@ const ce2 = ce.cloneWith({extension: "Value"});
 ### Example Applications
 
 There are a few trivial example applications in
-[the examples folder](https://github.com/cloudevents/sdk-javascript/tree/master/examples).
+[the examples folder](https://github.com/cloudevents/sdk-javascript/tree/main/examples).
 There you will find Express.js, TypeScript and Websocket examples.
 
 ## Supported specification features
@@ -150,7 +150,7 @@ There you will find Express.js, TypeScript and Websocket examples.
 ## Contributing
 
 We love contributions from the community! Please check the
-[Contributor's Guide](https://github.com/cloudevents/sdk-javascript/blob/master/CONTRIBUTING.md)
+[Contributor's Guide](https://github.com/cloudevents/sdk-javascript/blob/main/CONTRIBUTING.md)
 for information on how to get involved.
 
 Each SDK may have its own unique processes, tooling and guidelines, common
diff --git a/RELEASE_GUIDELINES.md b/RELEASE_GUIDELINES.md
@@ -6,15 +6,15 @@ To prepare for a new release, create a [new issue](https://github.com/cloudevent
 
 For example: "Proposal for 3.2.0 release", or something similar.  If you are not sure which version is the next version to be released, you can run `npm run release -- --dry-run` to find out what the next version will be.
 
-The body of the issue should be the commits that will be part of the release.  This can be easily accomplished by running a git log command with a defined **range**.  This range should start at the most recent version tag and end at the latest commit in the master branch.
+The body of the issue should be the commits that will be part of the release.  This can be easily accomplished by running a git log command with a defined **range**.  This range should start at the most recent version tag and end at the latest commit in the main branch.
 
 For example:
 
 ```
-git log v3.0.1..upstream/master --oneline
+git log v3.0.1..upstream/main --oneline
 ```
 
-This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/master branch.
+This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/main branch.
 
 This output should be pasted into the issue as normal text.  This will allow Github to magically turn all commit hashes and PR/Issues numbers to links.
 
@@ -37,7 +37,7 @@ npm run release
 This will update the CHANGELOG.md and create a new tag based on the version.  This can then be pushed upstream by doing:
 
 ```
-git push upstream master --follow-tags
+git push upstream main --follow-tags
 ```
 
 ### Create the release on GitHub
diff --git a/maintainer_guidelines.md b/maintainer_guidelines.md
@@ -26,15 +26,15 @@ When landing pull requests, be sure to check the first line uses an appropriate
 
 ## Branch Management
 
-The `master` branch is the bleeding edge. New major versions of the module
+The `main` branch is the bleeding edge. New major versions of the module
 are cut from this branch and tagged. If you intend to submit a pull request
-you should use `master HEAD` as your starting point.
+you should use `main HEAD` as your starting point.
 
 Each major release will result in a new branch and tag. For example, the
 release of version 1.0.0 of the module will result in a `v1.0.0` tag on the
 release commit, and a new branch `v1.x.y` for subsequent minor and patch
 level releases of that major version. However, development will continue
-apace on `master` for the next major version - e.g. 2.0.0. Version branches
+apace on `main` for the next major version - e.g. 2.0.0. Version branches
 are only created for each major version. Minor and patch level releases
 are simply tagged.
 
diff --git a/pr_guidelines.md b/pr_guidelines.md
@@ -5,13 +5,15 @@ a pull request in this repository. We hope it will help you have an easy time
 managing your work and a positive, satisfying experience when contributing
 your code. Thanks for getting involved! :rocket:
 
-* [Getting Started](#getting-started)
-* [Branches](#branches)
-* [Commit Messages](#commit-messages)
-* [Staying current with master](#staying-current-with-master)
-* [Style Guide](#style-guide)
-* [Submitting and Updating a Pull Request](#submitting-and-updating-a-pull-request)
-* [Congratulations!](#congratulations)
+- [Pull Request Guidelines](#pull-request-guidelines)
+  - [Getting Started](#getting-started)
+  - [Branches](#branches)
+  - [Commit Messages](#commit-messages)
+    - [Signing your commits](#signing-your-commits)
+  - [Staying Current with `main`](#staying-current-with-main)
+  - [Style Guide](#style-guide)
+  - [Submitting and Updating Your Pull Request](#submitting-and-updating-your-pull-request)
+  - [Congratulations!](#congratulations)
 
 ## Getting Started
 
@@ -35,7 +37,7 @@ you might create a branch named `48-fix-http-agent-error`.
 
 ```console
 git fetch upstream
-git reset --hard upstream/master
+git reset --hard upstream/main
 git checkout FETCH_HEAD
 git checkout -b 48-fix-http-agent-error
 ```
@@ -102,19 +104,19 @@ Date:   Thu Feb 2 11:41:15 2018 -0800
 Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will
 be rejected by the automated DCO check.
 
-## Staying Current with `master`
+## Staying Current with `main`
 
-As you are working on your branch, changes may happen on `master`. Before
+As you are working on your branch, changes may happen on `main`. Before
 submitting your pull request, be sure that your branch has been updated
 with the latest commits.
 
 ```console
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/main
 ```
 
 This may cause conflicts if the files you are changing on your branch are
-also changed on master. Error messages from `git` will indicate if conflicts
+also changed on main. Error messages from `git` will indicate if conflicts
 exist and what files need attention. Resolve the conflicts in each file, then
 continue with the rebase with `git rebase --continue`.
 
@@ -134,22 +136,22 @@ check your code style for linting errors without running tests, you can just
 run `npm run lint`. If there are errors, you can usually fix them automatically
 by running `npm run fix`.
 
-Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/master/.eslintrc).
+Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/main/.eslintrc).
 
 ## Submitting and Updating Your Pull Request
 
 Before submitting a pull request, you should make sure that all of the tests
 successfully pass by running `npm test`.
 
-Once you have sent your pull request, `master` may continue to evolve
-before your pull request has landed. If there are any commits on `master`
+Once you have sent your pull request, `main` may continue to evolve
+before your pull request has landed. If there are any commits on `main`
 that conflict with your changes, you may need to update your branch with
 these changes before the pull request can land. Resolve conflicts the same
 way as before.
 
 ```console
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/main
 # fix any potential conflicts
 git push -f origin 48-fix-http-agent-error
 ```
@@ -166,7 +168,7 @@ for details.
 
 ```console
 git commit -m "fixup: fix typo"
-git rebase -i upstream/master # follow git instructions
+git rebase -i upstream/main # follow git instructions
 ```
 
 Once you have rebased your commits, you can force push to your fork as before.

Original file line number	Diff line number	Diff line change
`@@ -1,12 +1,12 @@`
`1`	`1`	`<!-- General PR guidelines:`
`2`	`2`
`3`		`-Most PRs should be opened against the master branch.`
	`3`	`+Most PRs should be opened against the main branch.`
`4`	`4`
`5`	`5`	`-->`
`6`	`6`
`7`	`7`	`## Proposed Changes`
`8`	`8`
`9`		`--`
	`9`	`+-`
`10`	`10`	`-`
`11`	`11`	`-`
`12`	`12`