[DOCS] Update refs from master to main in USAGE.md etc (#1658)

* update refs from master to main in docs

CHANGELOG.next.md

@@ -32,7 +32,7 @@ Thanks, you're awesome :-) -->
 
 #### Improvements
 
-* Update refs from master to main in .github templates #1659
+* Update refs from master to main in USAGE.md etc #1658
 
 #### Deprecated
 

CONTRIBUTING.md

@@ -101,7 +101,7 @@ Please follow these guidelines when submitting Issues:
 
 ECS follows this branching strategy:
 
-* The `master` is the next major version. It is where all new contributions are first merged. This includes new features and bug fixes, and it may also include breaking changes.
+* The `main` is the next major version. It is where all new contributions are first merged. This includes new features and bug fixes, and it may also include breaking changes.
 * The `<major>.x` is the next minor version and gets backports of most non-breaking features and fixes.
 * The `<major>.<minor>` is the next release of a minor version, including patch releases.
 
@@ -116,7 +116,7 @@ Breaking changes intended for the next major version should be included undernea
 
 ### Backports
 
-ECS maintains multiple release branches in the repo. The `master` branch is where all new contributions should be submitted, and features and bug fixes will be backported into other branches when appropriate. Any backporting needs will be handled by the ECS team.
+ECS maintains multiple release branches in the repo. The `main` branch is where all new contributions should be submitted, and features and bug fixes will be backported into other branches when appropriate. Any backporting needs will be handled by the ECS team.
 
 #### Tooling
 

README.md

@@ -27,7 +27,7 @@ You can learn more in [generated/README.md](generated)
 
 ## Releases of ECS
 
-The master branch of this repository should never be considered an
+The main branch of this repository should never be considered an
 official release of ECS. You can browse official releases of ECS
 [here](https://github.com/elastic/ecs/releases).
 

USAGE.md

@@ -135,7 +135,7 @@ Running generator. ECS version 1.5.0
 **Points to note on the defaults**:
 
 * Artifacts are created in the [`generated`](generated) directory and the entire schema is included
-* Documentation updates will be written to the appropriate file under the `docs` directory. More specifics on generated doc files is covered in the [contributor's file](https://github.com/elastic/ecs/blob/master/CONTRIBUTING.md#generated-documentation-files)
+* Documentation updates will be written to the appropriate file under the `docs` directory. More specifics on generated doc files is covered in the [contributor's file](https://github.com/elastic/ecs/blob/main/CONTRIBUTING.md#generated-documentation-files)
 * Each run of the script will rewrite the entirety of the `generated` directory
 * The script will need to be executed from the top-level of the ECS repo
 * The `version` displayed when running `generator.py` is based on the current value of the [version](version) file in the top-level of the repo
@@ -164,7 +164,7 @@ Use the `--include` flag to generate ECS artifacts based on the current ECS sche
 $ python scripts/generator.py --include ../myproject/ecs/custom-fields/
 ```
 
-The `--include` flag expects a directory of schema YAML files using the same [file format](https://github.com/elastic/ecs/tree/master/schemas#fields-supported-in-schemasyml) as the ECS schema files. This is useful for maintaining custom field definitions that are _outside_ of the ECS schema, but allows for merging the custom fields with the official ECS fields for your deployment.
+The `--include` flag expects a directory of schema YAML files using the same [file format](https://github.com/elastic/ecs/tree/main/schemas#fields-supported-in-schemasyml) as the ECS schema files. This is useful for maintaining custom field definitions that are _outside_ of the ECS schema, but allows for merging the custom fields with the official ECS fields for your deployment.
 
 For example, if we defined the following schema definition in a file named `myproject/ecs/custom-fields/widget.yml`:
 
@@ -234,14 +234,14 @@ Include can be used together with the `--ref` flag to merge custom fields into a
 
 #### Exclude
 
-Use the `--exclude` flag to generate ephemeral ECS artifacts based on the current ECS schema field definitions minus fields considered for removal, e.g. to assess impact of removing these. Warning! This is not the recommended route to remove a field permanently as it is not intended to be invoked during the build process. Definitive field removal should be implemented using a custom [Subset](#subset) or via the [RFC process](https://github.com/elastic/ecs/tree/master/rfcs/README.md). Example:
+Use the `--exclude` flag to generate ephemeral ECS artifacts based on the current ECS schema field definitions minus fields considered for removal, e.g. to assess impact of removing these. Warning! This is not the recommended route to remove a field permanently as it is not intended to be invoked during the build process. Definitive field removal should be implemented using a custom [Subset](#subset) or via the [RFC process](https://github.com/elastic/ecs/tree/main/rfcs/README.md). Example:
 
 ```
 $ python scripts/generator.py --exclude=../my-project/my-exclude-file.yml
 $ python scripts/generator.py --exclude="../my-project/schemas/a*.yml"
 ```
 
-The `--exclude` flag expects a path to one or more YAML files using the same [file format](https://github.com/elastic/ecs/tree/master/schemas#fields-supported-in-schemasyml) as the ECS schema files. You can also use a subset, provided that relevant `name` and `fields` fields are preserved.
+The `--exclude` flag expects a path to one or more YAML files using the same [file format](https://github.com/elastic/ecs/tree/main/schemas#fields-supported-in-schemasyml) as the ECS schema files. You can also use a subset, provided that relevant `name` and `fields` fields are preserved.
 
 ```
 ---

stages.html

@@ -26,7 +26,7 @@
 
 <h1>ECS Proposal Stages</h1>
 
-<p>These are the stages that an individual RFC advances through before being released for general availability in the Elastic Common Schema (ECS). See the <a href="https://github.com/elastic/ecs/blob/master/rfcs/PROCESS.md">Contributing Guide</a> for broader details about contributing changes to ECS through the RFC process.
+<p>These are the stages that an individual RFC advances through before being released for general availability in the Elastic Common Schema (ECS). See the <a href="https://github.com/elastic/ecs/blob/main/rfcs/PROCESS.md">Contributing Guide</a> for broader details about contributing changes to ECS through the RFC process.
 
 <table>
   <thead>