Merge pull request libgit2#5925 from Batchyx/batchyx/master-to-main-doc

docs: stop mentioning libgit2's "master" branch

Author: ethomson

docs/contributing.md

@@ -35,7 +35,7 @@ easily accessible permanent record of the conversation.
 
 ## Libgit2 Versions
 
-The `master` branch is the main branch where development happens.
+The `main` branch is the main branch where development happens.
 Releases are tagged
 (e.g. [v0.21.0](https://github.com/libgit2/libgit2/releases/tag/v0.21.0) )
 and when a critical bug fix needs to be backported, it will be done on a
@@ -51,7 +51,7 @@ commit SHA
 Using [`git describe`](http://git-scm.com/docs/git-describe) is a
 great way to tell us what version you're working with.
 
-If you're not running against the latest `master` branch version,
+If you're not running against the latest `main` branch version,
 please compile and test against that to avoid re-reporting an issue that's
 already been fixed.
 
@@ -68,11 +68,11 @@ flow](https://guides.github.com/introduction/flow/index.html), where
 contributors fork the [libgit2 repository](https://github.com/libgit2/libgit2),
 make their changes on branch, and submit a
 [Pull Request](https://help.github.com/articles/using-pull-requests)
-(a.k.a. "PR").  Pull requests should usually be targeted at the `master`
+(a.k.a. "PR").  Pull requests should usually be targeted at the `main`
 branch.
 
 Life will be a lot easier for you (and us) if you follow this pattern
-(i.e. fork, named branch, submit PR).  If you use your fork's `master`
+(i.e. fork, named branch, submit PR).  If you use your fork's `main`
 branch directly, things can get messy.
 
 Please include a nice description of your changes when you submit your PR;

docs/release.md

@@ -1,6 +1,6 @@
 # Releasing the library
 
-We have three kinds of releases: "full" releases, maintenance releases and security releases. Full ones release the state of the `master` branch whereas maintenance releases provide bugfixes building on top of the currently released series. Security releases are also for the current series but only contain security fixes on top of the previous release.
+We have three kinds of releases: "full" releases, maintenance releases and security releases. Full ones release the state of the `main` branch whereas maintenance releases provide bugfixes building on top of the currently released series. Security releases are also for the current series but only contain security fixes on top of the previous release.
 
 ## Full release
 
@@ -40,7 +40,7 @@ followed by the three sections in the changelog. For release candidates we can a
 
 During the freeze, and certainly after the first release candidate, any bindings the core team work with should be updated in order to discover any issues that might come up with the multitude of approaches to memory management, embedding or linking.
 
-Create a branch `maint/v0.X` at the current state of `master` after you've created the tag. This will be used for maintenance releases and lets our dependents track the latest state of the series.
+Create a branch `maint/v0.X` at the current state of `main` after you've created the tag. This will be used for maintenance releases and lets our dependents track the latest state of the series.
 
 ## Maintenance release
 
@@ -76,7 +76,7 @@ We use docurium to generate our documentation. It is a tool written in ruby whic
 
     gem install docurium
 
-and run it against our description file with the tip of master checked out.
+and run it against our description file with the tip of `main` checked out.
 
     cm doc api.docurium