You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: contribute/contribute-guide.md
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Guidelines for contributing to Docker's docs
4
4
keywords: contribute, guide, style guide
5
5
---
6
6
7
-
The live docs are published from the `master` branch. Therefore, you must create pull requests against the `master` branch for all content updates. This includes:
7
+
The live docs are published from the `main` branch. Therefore, you must create pull requests against the `main` branch for all content updates. This includes:
8
8
9
9
- Conceptual and task-based information
10
10
- Restructuring / rewriting
@@ -17,7 +17,7 @@ There are two ways to contribute a pull request to the docs repository:
17
17
18
18
This opens the GitHub editor, which means you don't need to know a lot about Git, or even about Markdown. When you save, Git prompts you to create a fork if you don't already have one, and to create a branch in your fork and submit the pull request.
19
19
20
-
2. Fork the [docs GitHub repository]({{ site.repo }}). Suggest changes or add new content on your local branch, and submit a pull request (PR) to the `master` branch.
20
+
2. Fork the [docs GitHub repository]({{ site.repo }}). Suggest changes or add new content on your local branch, and submit a pull request (PR) to the `main` branch.
21
21
22
22
This is the manual, more advanced version of clicking 'Edit this page' on a published docs page. Initiating a docs changes in a PR from your own branch gives you more flexibility, as you can submit changes to multiple pages or files under a single pull request, and even create new topics.
23
23
@@ -44,7 +44,7 @@ Help us review your PRs more quickly by following these guidelines.
44
44
- Don't change whitespace or line wrapping in parts of a file you are not editing for other reasons. Make sure your text editor is not configured to
45
45
automatically reformat the whole file when saving.
46
46
- We highly recommend that you [build](#build-and-preview-the-docs-locally) and [test](#test-the-docs-locally) the docs locally before submitting a PR.
47
-
- A Netlify test runs for each PR that is against the `master` branch, and deploys the result of your PR to a staging site. The URL will be available at in the **Conversation** tab. Check the staging site to verify how your changes look and fix issues, if necessary.
47
+
- A Netlify test runs for each PR that is against the `main` branch, and deploys the result of your PR to a staging site. The URL will be available at in the **Conversation** tab. Check the staging site to verify how your changes look and fix issues, if necessary.
48
48
49
49
### Collaborate on a pull request
50
50
@@ -56,11 +56,11 @@ given file in the **Files** view.
56
56
57
57
If a PR consists of multiple small addendum commits on top of a more significant
58
58
one, the commit will usually be "squash-merged", so that only one commit is
59
-
merged into the `master` branch. In some scenarios where a squash and merge isn't appropriate, all commits are kept separate when merging.
59
+
merged into the `main` branch. In some scenarios where a squash and merge isn't appropriate, all commits are kept separate when merging.
60
60
61
61
### Per-PR staging on GitHub
62
62
63
-
A Netlify test runs for each PR created against the `master` branch and deploys the result of your PR to a staging site. When the site builds successfully, you will see a comment in the **Conversation** tab in the PR stating **Deploy Preview for docsdocker ready!**. Click the **Browse the preview** URL and check the staging site to verify how your changes look and fix issues, if necessary. Reviewers also check the staged site before merging the PR to protect the integrity of the docs site.
63
+
A Netlify test runs for each PR created against the `main` branch and deploys the result of your PR to a staging site. When the site builds successfully, you will see a comment in the **Conversation** tab in the PR stating **Deploy Preview for docsdocker ready!**. Click the **Browse the preview** URL and check the staging site to verify how your changes look and fix issues, if necessary. Reviewers also check the staged site before merging the PR to protect the integrity of the docs site.
0 commit comments