diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2ba38839..b6ad0c38 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -50,16 +50,16 @@ The Git LFS teams mark issues and pull requests with the following labels:
 
 ## Branching strategy
 
-In general, contributors should develop on branches based off of `master` and pull requests should be to `master`.
+In general, contributors should develop on branches based off of `main` and pull requests should be to `main`.
 
 ## Submitting a pull request
 
 1. [Fork][] and clone the repository
 1. Configure and install the dependencies: `make`
 1. Make sure the tests pass on your machine: `make test`
-1. Create a new branch based on `master`: `git checkout -b <my-branch-name> master`
+1. Create a new branch based on `main`: `git checkout -b <my-branch-name> main`
 1. Make your change, add tests, and make sure the tests still pass
-1. Push to your fork and [submit a pull request][pr] from your branch to `master`
+1. Push to your fork and [submit a pull request][pr] from your branch to `main`
 1. Pat yourself on the back and wait for your pull request to be reviewed
 
 Here are a few things you can do that will increase the likelihood of your pull request being accepted:
diff --git a/README.md b/README.md
index 33c02b06..64eae3a1 100644
--- a/README.md
+++ b/README.md
@@ -116,7 +116,7 @@ $ git commit -m "add psd"
 > $ git lfs migrate import --include="*.psd" --everything
 > ```
 >
-> For more information, read [`git-lfs-migrate(1)`](https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn).
+> For more information, read [`git-lfs-migrate(1)`](https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-migrate.1.ronn).
 
 You can confirm that Git LFS is managing your PSD file:
 
diff --git a/docs/howto/release-git-lfs.md b/docs/howto/release-git-lfs.md
index 58260838..d86f100e 100644
--- a/docs/howto/release-git-lfs.md
+++ b/docs/howto/release-git-lfs.md
@@ -50,13 +50,13 @@ We package several artifacts for each tagged release. They are:
 
 ## Development Philosophy
 
-We do all major development on the `master` branch, and assume it to be passing
+We do all major development on the `main` branch, and assume it to be passing
 tests at all times. New features are added via the feature-branch workflow, or
 (optionally) from a contributor's fork.
 
-This is done so that `master` can progress and grow new features, while
+This is done so that `main` can progress and grow new features, while
 historical releases, such as `v2.n.0` can receive bug fixes as they are applied
-to master, eventually culminating in a `v2.n.1` (and so on) release.
+to main, eventually culminating in a `v2.n.1` (and so on) release.
 
 ## Building a release
 
@@ -89,7 +89,7 @@ equal to 0, we say that we are releasing a MINOR version of Git LFS, in the
        the relevant files.
 
   2. Then, create a pull request of your changes with head `release-next`. If
-     you're building a MAJOR or MINOR release, set the base to `master`.
+     you're building a MAJOR or MINOR release, set the base to `main`.
      Otherwise, set the base to `release-2.n`.
 
      Run Continuous Integration, and ensure that it passes.
@@ -171,14 +171,14 @@ equal to 0, we say that we are releasing a MINOR version of Git LFS, in the
 When building a MINOR release, we introduce a new `release-2.n` branch which
 will receive all new features and bug fixes since `release-2.n-1`. The change
 set described by `v2.n-1.0` and `v2.n.0` is as reported by `git log
-v2.n-1.0...master` at the time of release.
+v2.n-1.0...main` at the time of release.
 
   1. To introduce this new branch (after creating and merging `release-next`
-     into `master`), simply run:
+     into `main`), simply run:
 
      ```ShellSession
      $ git branch
-     * master
+     * main
      $ git checkout -b release-2.n
      ```
 
@@ -187,7 +187,7 @@ v2.n-1.0...master` at the time of release.
 ### Building `v2.n.m` (PATCH versions)
 
 When building a PATCH release, follow the same process as above, with the
-additional caveat that we must cherry-pick merges from master to the release
+additional caveat that we must cherry-pick merges from main to the release
 branch.
 
   1. To begin, checkout the branch `release-2.n`, and ensure that you have the
@@ -197,7 +197,7 @@ branch.
      with:
 
      ```ShellSession
-     $ git log --merges --first-parent v2.n.m-1...master
+     $ git log --merges --first-parent v2.n.m-1...main
      ```
 
    3. For each merge that you want to backport, run:
diff --git a/docs/man/git-lfs-config.5.ronn b/docs/man/git-lfs-config.5.ronn
index 584d6571..499dc87b 100644
--- a/docs/man/git-lfs-config.5.ronn
+++ b/docs/man/git-lfs-config.5.ronn
@@ -133,7 +133,7 @@ be scoped inside the configuration for a remote.
   using any mechanism you like (rather than just HTTP). `path` should point to
   the process you wish to invoke. The protocol between the git-lfs client and
   the custom transfer process is documented at
-  https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md
+  https://github.com/git-lfs/git-lfs/blob/main/docs/custom-transfers.md
 
   <name> must be a unique identifier that the LFS server understands. When
   calling the LFS API the client will include a list of supported transfer