Update reference of master to main in docs

.github/ISSUE_TEMPLATE/bug-report.md

@@ -14,7 +14,7 @@ about what components it touches e.g "query:" or ".*:"
 -->
 
 <!--
-In case of issues related to exact bucket implementation, please ping corresponded maintainer from list here: https://github.com/thanos-io/thanos/blob/master/docs/storage.md
+In case of issues related to exact bucket implementation, please ping corresponded maintainer from list here: https://github.com/thanos-io/thanos/blob/main/docs/storage.md
 -->
 
 **Thanos, Prometheus and Golang version used**:
@@ -23,7 +23,7 @@ In case of issues related to exact bucket implementation, please ping correspond
 Output of "thanos --version" or docker image:tag used.
 (Double-check if all deployed components/services have expected versions)
 
-If you are using custom build from master branch, have you checked out the tip of the master?
+If you are using custom build from main branch, have you checked out the tip of the main?
 -->
 
 **Object Storage Provider**:

CONTRIBUTING.md

@@ -99,7 +99,7 @@ $ git clone https://github.com/<your_github_id>/thanos.git
 $ cd thanos
 $ git remote add upstream https://github.com/thanos-io/thanos.git
 $ git remote update
-$ git merge upstream/master
+$ git merge upstream/main
 $ make build
 $ export PATH=$PATH:$GOPATH/bin
 $ thanos -h
@@ -118,13 +118,13 @@ You can also alias ``commit`` as `commit -s` in your `~/.gitconfig` to signoff a
 
 If you have authored an unsigned commit, you can update it using ``git commit --amend --signoff``. If you've pushed your changes to GitHub already you'll need to force push your branch after this with ``git push -f``.
 
-1. Keep PRs as small as possible. For each of your PRs, you create a new branch based on the latest master.
+1. Keep PRs as small as possible. For each of your PRs, you create a new branch based on the latest main.
 Chain them if needed (base one PR on other PRs). You can read more details about the workflow from [here](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
 
 ```console
-$ git checkout master
+$ git checkout main
 $ git remote update
-$ git merge upstream/master
+$ git merge upstream/main
 $ git checkout -b <your_branch_for_new_pr>
 $ make build
 $ <Iterate your development>

Makefile

@@ -294,7 +294,7 @@ lint: go-lint react-app-lint shell-lint
 # to debug big allocations during linting.
 .PHONY: go-lint
 go-lint: check-git deps $(GOLANGCI_LINT) $(FAILLINT)
-	$(call require_clean_work_tree,'detected not clean master before running lint, previous job changed something?')
+	$(call require_clean_work_tree,'detected not clean work tree before running lint, previous job changed something?')
 	@echo ">> verifying modules being imported"
 	@# TODO(bwplotka): Add, Printf, DefaultRegisterer, NewGaugeFunc and MustRegister once exception are accepted. Add fmt.{Errorf}=github.com/pkg/errors.{Errorf} once https://github.com/fatih/faillint/issues/10 is addressed.
 	@$(FAILLINT) -paths "errors=github.com/pkg/errors,\

README.md

@@ -71,7 +71,7 @@ The philosophy of Thanos and our community is borrowing much from UNIX philosoph
 
 ## Releases
 
-Master should be stable and usable. Every commit to master builds docker image named `master-<date>-<sha>` in [quay.io/thanos/thanos](https://quay.io/repository/thanos/thanos) and [thanosio/thanos dockerhub (mirror)](https://hub.docker.com/r/thanosio/thanos)
+Main branch should be stable and usable. Every commit to main builds docker image named `main-<date>-<sha>` in [quay.io/thanos/thanos](https://quay.io/repository/thanos/thanos) and [thanosio/thanos dockerhub (mirror)](https://hub.docker.com/r/thanosio/thanos)
 
 We also perform minor releases every 6 weeks.
 

doc.go

@@ -5,5 +5,5 @@
 // can provide highly available Prometheus
 // setup with long term storage capabilities.
 //
-// See https://github.com/thanos-io/thanos/blob/master/docs/getting_started.md for first steps.
+// See https://github.com/thanos-io/thanos/blob/main/docs/getting_started.md for first steps.
 package thanos // import "github.com/thanos-io/thanos"

docs/components/query.md

@@ -8,7 +8,7 @@ menu: components
 
 The `thanos query` command (also known as "Querier") implements the [Prometheus HTTP v1 API](https://prometheus.io/docs/prometheus/latest/querying/api/) to query data in a Thanos cluster via PromQL.
 
-In short, it gathers the data needed to evaluate the query from underlying [StoreAPIs](https://github.com/thanos-io/thanos/blob/master/pkg/store/storepb/rpc.proto), evaluates the query and returns the result.
+In short, it gathers the data needed to evaluate the query from underlying [StoreAPIs](https://github.com/thanos-io/thanos/blob/main/pkg/store/storepb/rpc.proto), evaluates the query and returns the result.
 
 Querier is fully stateless and horizontally scalable.
 

docs/contributing/how-to-contribute-to-docs.md

@@ -83,7 +83,7 @@ Copy your company's logo in [`website/static/logos`](/website/static/logos), mak
 * Greyscale is preferred but color is fine
 * Keep it under 50KB
 
-and create PR against Thanos `master` branch.
+and create PR against Thanos `main` branch.
 
 ## White noise
 
@@ -108,9 +108,9 @@ make web-serve
 
 We use [Netlify](https://www.netlify.com/) for hosting. We are using Open Source license (PRO). Thanks Netlify for this!
 
-On every commit to `master` netlify runs CI that invokes `make web` (defined in [netlify.toml](/netlify.toml))
+On every commit to `main` netlify runs CI that invokes `make web` (defined in [netlify.toml](/netlify.toml))
 
 NOTE: Check for status badge in README for build status on the page.
 
-If master build for netlify succeed, the new content is published automatically.
+If main build for netlify succeed, the new content is published automatically.
 

docs/getting-started.md

@@ -32,7 +32,7 @@ Thanos aims for a simple deployment and maintenance model. The only dependencies
 
 You can find the latest Thanos release [here](https://github.com/thanos-io/thanos/releases).
 
-Master should be stable and usable. Every commit to master builds docker image named `master-<data>-<sha>` in
+Main should be stable and usable. Every commit to main builds docker image named `main-<data>-<sha>` in
 [quay.io/thanos/thanos](https://quay.io/repository/thanos/thanos) and [thanosio/thanos dockerhub (mirror)](https://hub.docker.com/r/thanosio/thanos)
 
 We also perform minor releases every 6 weeks.
@@ -90,7 +90,7 @@ If you want to add yourself to this list, let us know!
 
 ## Operating
 
-See up to date [jsonnet mixins](https://github.com/thanos-io/thanos/tree/master/mixin/README.md)
+See up to date [jsonnet mixins](https://github.com/thanos-io/thanos/tree/main/mixin/README.md)
 We also have example Grafana dashboards [here](/examples/dashboards/dashboards.md) and some [alerts](/examples/alerts/alerts.md) to get you started.
 
 ## Talks

docs/integrations.md

@@ -8,7 +8,7 @@ menu: thanos
 
 ## StoreAPI
 
-[StoreAPI](https://github.com/thanos-io/thanos/blob/master/pkg/store/storepb/rpc.proto) is a common proto interface for gRPC component
+[StoreAPI](https://github.com/thanos-io/thanos/blob/main/pkg/store/storepb/rpc.proto) is a common proto interface for gRPC component
 that can connect to [Querier](../components/query.md) in order to fetch the metric series.
 Natively Thanos implements [Sidecar](../components/sidecar.md) (local Prometheus data),
 [Ruler](../components/rule.md) and [Store gateway](../components/store.md).

docs/release-process.md

@@ -20,7 +20,7 @@ into being within release (except bug fixes).
 
 No feature should block release.
 
-Additionally we (obviously) aim for `master` branch being stable.
+Additionally we (obviously) aim for `main` branch being stable.
 
 We are assigning a release shepherd for each minor release.
 
@@ -54,7 +54,7 @@ Process of releasing a *minor* Thanos version:
 1. Release `v<major>.<minor+1>.0-rc.0`
 1. If after 3 work days there is no major bug, release `v<major>.<minor>.0`
 1. If within 3 work days there is major bug, let's triage it to fix it and then release `v<major>.<minor>.0-rc.++` Go to step 2.
-1. Do patch release if needed for any bugs afterwards. Use same `release-xxx` branch and migrate fixes to master.
+1. Do patch release if needed for any bugs afterwards. Use same `release-xxx` branch and migrate fixes to main.
 
 ## How to release a version
 
@@ -70,7 +70,7 @@ Release is happening on separate `release-<major>.<minor>` branch.
 
   For release candidate just reuse same branch and rebase it on every candidate until the actual release happens.
 
-1. Create small PR to master (!) to cut CHANGELOG. This helps to maintain new changelog on master. For example: https://github.com/thanos-io/thanos/pull/2627
+1. Create small PR to main (!) to cut CHANGELOG. This helps to maintain new changelog on main. For example: https://github.com/thanos-io/thanos/pull/2627
 
 1. Update [CHANGELOG file](/CHANGELOG.md)
 
@@ -121,7 +121,7 @@ Release is happening on separate `release-<major>.<minor>` branch.
 
  1. Announce `#thanos` slack channel.
 
- 1. Pull commits from release branch to master branch for non `rc` releases.
+ 1. Pull commits from release branch to main branch for non `rc` releases.
 
 ## Pre-releases (release candidates)