whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reformat the open a PR page

Browse Source
This commit is contained in:
Qiming Teng
2022-06-18 15:19:45 +08:00
parent 3332857e51
commit aa585d2c29
1 changed files with 283 additions and 246 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/contribute/new-content/open-a-pr.md
+283 -246
View File
@@ -15,13 +15,15 @@ upcoming Kubernetes release, see
[Document a new feature](/docs/contribute/new-content/new-features/). [Document a new feature](/docs/contribute/new-content/new-features/).
{{< /note >}} {{< /note >}}
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section. To contribute new content pages or improve existing content pages, open a pull request (PR).
Make sure you follow all the requirements in the
If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page. [Before you begin](/docs/contribute/new-content/) section.
If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer.
If your change is small, or you're unfamiliar with git, read
[Changes using GitHub](#changes-using-github) to learn how to edit a page.
If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make
changes locally on your computer.
<!-- body --> <!-- body -->
@@ -63,38 +65,39 @@ class id1 k8s
Figure 1. Steps for opening a PR using GitHub. Figure 1. Steps for opening a PR using GitHub.
1. On the page where you see the issue, select the pencil icon at the top right. 1. On the page where you see the issue, select the pencil icon at the top right.
You can also scroll to the bottom of the page and select **Edit this page**. You can also scroll to the bottom of the page and select **Edit this page**.
2. Make your changes in the GitHub markdown editor. 1. Make your changes in the GitHub markdown editor.
3. Below the editor, fill in the **Propose file change** 1. Below the editor, fill in the **Propose file change** form.
form. In the first field, give your commit message a title. In In the first field, give your commit message a title.
the second field, provide a description. In the second field, provide a description.
{{< note >}} {{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
description later. in your commit message. You can add those to the pull request description later.
{{< /note >}} {{< /note >}}
4. Select **Propose file change**. 1. Select **Propose file change**.
5. Select **Create pull request**. 1. Select **Create pull request**.
6. The **Open a pull request** screen appears. Fill in the form: 1. The **Open a pull request** screen appears. Fill in the form:
- The **Subject** field of the pull request defaults to the commit summary. - The **Subject** field of the pull request defaults to the commit summary.
You can change it if needed. You can change it if needed.
- The **Body** contains your extended commit message, if you have one, - The **Body** contains your extended commit message, if you have one,
and some template text. Add the and some template text. Add the
details the template text asks for, then delete the extra template text. details the template text asks for, then delete the extra template text.
- Leave the **Allow edits from maintainers** checkbox selected. - Leave the **Allow edits from maintainers** checkbox selected.
{{< note >}} {{< note >}}
PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr). PR descriptions are a great way to help reviewers understand your change.
{{</ note >}} For more information, see [Opening a PR](#open-a-pr).
{{</ note >}}
7. Select **Create pull request**. 1. Select **Create pull request**.
### Addressing feedback in GitHub ### Addressing feedback in GitHub
@@ -106,12 +109,12 @@ leave a comment with their GitHub username in it.
If a reviewer asks you to make changes: If a reviewer asks you to make changes:
1. Go to the **Files changed** tab. 1. Go to the **Files changed** tab.
2. Select the pencil (edit) icon on any files changed by the 1. Select the pencil (edit) icon on any files changed by the pull request.
pull request. 1. Make the changes requested.
3. Make the changes requested. 1. Commit the changes.
4. Commit the changes.
If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel. If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the
`#sig-docs` Slack channel.
When your review is complete, a reviewer merges your PR and your changes go live a few minutes later. When your review is complete, a reviewer merges your PR and your changes go live a few minutes later.
@@ -120,7 +123,8 @@ When your review is complete, a reviewer merges your PR and your changes go live
If you're more experienced with git, or if your changes are larger than a few lines, If you're more experienced with git, or if your changes are larger than a few lines,
work from a local fork. work from a local fork.
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application. Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed
on your computer. You can also use a git UI application.
Figure 2 shows the steps to follow when you work from a local fork. The details for each step follow. Figure 2 shows the steps to follow when you work from a local fork. The details for each step follow.
@@ -157,53 +161,56 @@ Figure 2. Working from a local fork to make your changes.
### Fork the kubernetes/website repository ### Fork the kubernetes/website repository
1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. 1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **Fork**. 1. Select **Fork**.
### Create a local clone and set the upstream ### Create a local clone and set the upstream
3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme): 1. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme):
```bash ```shell
git clone git@github.com/<github_username>/website git clone git@github.com/<github_username>/website
cd website cd website
git submodule update --init --recursive --depth 1 git submodule update --init --recursive --depth 1
``` ```
4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: 1. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
```bash ```shell
cd website cd website
git remote add upstream https://github.com/kubernetes/website.git git remote add upstream https://github.com/kubernetes/website.git
``` ```
5. Confirm your `origin` and `upstream` repositories: 1. Confirm your `origin` and `upstream` repositories:
```bash ```shell
git remote -v git remote -v
``` ```
Output is similar to: Output is similar to:
```bash ```none
origin git@github.com:<github_username>/website.git (fetch) origin git@github.com:<github_username>/website.git (fetch)
origin git@github.com:<github_username>/website.git (push) origin git@github.com:<github_username>/website.git (push)
upstream https://github.com/kubernetes/website.git (fetch) upstream https://github.com/kubernetes/website.git (fetch)
upstream https://github.com/kubernetes/website.git (push) upstream https://github.com/kubernetes/website.git (push)
``` ```
6. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`: 1. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`:
```bash ```shell
git fetch origin git fetch origin
git fetch upstream git fetch upstream
``` ```
This makes sure your local repository is up to date before you start making changes. This makes sure your local repository is up to date before you start making changes.
{{< note >}} {{< note >}}
This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `main` with `upstream/main` before pushing updates to your fork. This workflow is different than the
{{< /note >}} [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md).
You do not need to merge your local copy of `main` with `upstream/main` before pushing updates
to your fork.
{{< /note >}}
### Create a branch ### Create a branch
@@ -211,21 +218,23 @@ Figure 2. Working from a local fork to make your changes.
- For improvements to existing content, use `upstream/main`. - For improvements to existing content, use `upstream/main`.
- For new content about existing features, use `upstream/main`. - For new content about existing features, use `upstream/main`.
- For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/). - For localized content, use the localization's conventions. For more information, see
- For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/). [localizing Kubernetes documentation](/docs/contribute/localization/).
- For new features in an upcoming Kubernetes release, use the feature branch. For more
information, see [documenting for a release](/docs/contribute/new-content/new-features/).
- For long-running efforts that multiple SIG Docs contributors collaborate on, - For long-running efforts that multiple SIG Docs contributors collaborate on,
like content reorganization, use a specific feature branch created for that like content reorganization, use a specific feature branch created for that effort.
effort.
If you need help choosing a branch, ask in the `#sig-docs` Slack channel. If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`: 1. Create a new branch based on the branch identified in step 1. This example assumes the base
branch is `upstream/main`:
```bash ```shell
git checkout -b <my_new_branch> upstream/main git checkout -b <my_new_branch> upstream/main
``` ```
3. Make your changes using a text editor. 3. Make your changes using a text editor.
At any time, use the `git status` command to see what files you've changed. At any time, use the `git status` command to see what files you've changed.
@@ -235,109 +244,116 @@ When you are ready to submit a pull request, commit your changes.
1. In your local repository, check which files you need to commit: 1. In your local repository, check which files you need to commit:
```bash ```shell
git status git status
``` ```
Output is similar to: Output is similar to:
```bash ```none
On branch <my_new_branch> On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'. Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit: Changes not staged for commit:
(use "git add <file>..." to update what will be committed) (use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory) (use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a") no changes added to commit (use "git add" and/or "git commit -a")
``` ```
2. Add the files listed under **Changes not staged for commit** to the commit: 1. Add the files listed under **Changes not staged for commit** to the commit:
```bash ```shell
git add <your_file_name> git add <your_file_name>
``` ```
Repeat this for each file. Repeat this for each file.
3. After adding all the files, create a commit: 1. After adding all the files, create a commit:
```bash ```shell
git commit -m "Your commit message" git commit -m "Your commit message"
``` ```
{{< note >}} {{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
description later. in your commit message. You can add those to the pull request
{{< /note >}} description later.
{{< /note >}}
4. Push your local branch and its new commit to your remote fork: 1. Push your local branch and its new commit to your remote fork:
```bash ```shell
git push origin <my_new_branch> git push origin <my_new_branch>
``` ```
### Preview your changes locally {#preview-locally} ### Preview your changes locally {#preview-locally}
It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. It's a good idea to preview your changes locally before pushing them or opening a pull request.
A preview lets you catch build errors or markdown formatting problems.
You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. You can either build the website's container image or run Hugo locally. Building the container
image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can
be useful for debugging.
{{< tabs name="tab_with_hugo" >}} {{< tabs name="tab_with_hugo" >}}
{{% tab name="Hugo in a container" %}} {{% tab name="Hugo in a container" %}}
{{< note >}} {{< note >}}
The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour. The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment
variable to override this behaviour.
{{< /note >}} {{< /note >}}
1. Build the container image locally 1. Build the container image locally
_You only need this step if you are testing a change to the Hugo tool itself_ _You only need this step if you are testing a change to the Hugo tool itself_
```bash
```shell
# Run this in a terminal (if required) # Run this in a terminal (if required)
make container-image make container-image
``` ```
1. Start Hugo in a container: 1. Start Hugo in a container:
```bash ```shell
# Run this in a terminal # Run this in a terminal
make container-serve make container-serve
``` ```
1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the 1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
changes and rebuilds the site as needed. changes and rebuilds the site as needed.
1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, 1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window. or close the terminal window.
{{% /tab %}} {{% /tab %}}
{{% tab name="Hugo on the command line" %}} {{% tab name="Hugo on the command line" %}}
Alternately, install and use the `hugo` command on your computer: Alternately, install and use the `hugo` command on your computer:
1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml). 1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in
[`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml).
2. If you have not updated your website repository, the `website/themes/docsy` directory is empty. 1. If you have not updated your website repository, the `website/themes/docsy` directory is empty.
The site cannot build without a local copy of the theme. To update the website theme, run: The site cannot build without a local copy of the theme. To update the website theme, run:
```bash ```shell
git submodule update --init --recursive --depth 1 git submodule update --init --recursive --depth 1
``` ```
3. In a terminal, go to your Kubernetes website repository and start the Hugo server: 1. In a terminal, go to your Kubernetes website repository and start the Hugo server:
```bash ```shell
cd <path_to_your_repo>/website cd <path_to_your_repo>/website
hugo server --buildFuture hugo server --buildFuture
``` ```
4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the 1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
changes and rebuilds the site as needed. changes and rebuilds the site as needed.
5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, 1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window. or close the terminal window.
{{% /tab %}} {{% /tab %}}
{{< /tabs >}} {{< /tabs >}}
@@ -345,6 +361,7 @@ Alternately, install and use the `hugo` command on your computer:
### Open a pull request from your fork to kubernetes/website {#open-a-pr} ### Open a pull request from your fork to kubernetes/website {#open-a-pr}
Figure 3 shows the steps to open a PR from your fork to the K8s/website. The details follow. Figure 3 shows the steps to open a PR from your fork to the K8s/website. The details follow.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure --> <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it --> <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@@ -374,47 +391,55 @@ class first,second white
Figure 3. Steps to open a PR from your fork to the K8s/website. Figure 3. Steps to open a PR from your fork to the K8s/website.
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **New Pull Request**. 1. Select **New Pull Request**.
3. Select **compare across forks**. 1. Select **compare across forks**.
4. From the **head repository** drop-down menu, select your fork. 1. From the **head repository** drop-down menu, select your fork.
5. From the **compare** drop-down menu, select your branch. 1. From the **compare** drop-down menu, select your branch.
6. Select **Create Pull Request**. 1. Select **Create Pull Request**.
7. Add a description for your pull request: `. Add a description for your pull request:
- **Title** (50 characters or less): Summarize the intent of the change. - **Title** (50 characters or less): Summarize the intent of the change.
- **Description**: Describe the change in more detail. - **Description**: Describe the change in more detail.
- If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well.
- If you want advice on something specific, include any questions you'd like reviewers to think about in your description.
8. Select the **Create pull request** button. - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the
description. GitHub's automation closes the mentioned issue after merging the PR if used.
If there are other related PRs, link those as well.
- If you want advice on something specific, include any questions you'd like reviewers to
think about in your description.
1. Select the **Create pull request** button.
Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls). Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
After opening a PR, GitHub runs automated tests and tries to deploy a preview using
[Netlify](https://www.netlify.com/).
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/). - If the Netlify build fails, select **Details** for more information.
- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes
website with your changes applied. This is how reviewers check your changes.
- If the Netlify build fails, select **Details** for more information. GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if
- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes. needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels).
GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels).
### Addressing feedback locally ### Addressing feedback locally
1. After making your changes, amend your previous commit: 1. After making your changes, amend your previous commit:
```bash ```shell
git commit -a --amend git commit -a --amend
``` ```
- `-a`: commits all changes - `-a`: commits all changes
- `--amend`: amends the previous commit, rather than creating a new one - `--amend`: amends the previous commit, rather than creating a new one
2. Update your commit message if needed. 1. Update your commit message if needed.
3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests. 1. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests.
{{< note >}} {{< note >}}
If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging. If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits)
{{< /note >}} before merging.
{{< /note >}}
#### Changes from reviewers #### Changes from reviewers
@@ -422,89 +447,97 @@ Sometimes reviewers commit to your pull request. Before making any other changes
1. Fetch commits from your remote fork and rebase your working branch: 1. Fetch commits from your remote fork and rebase your working branch:
```bash ```shell
git fetch origin git fetch origin
git rebase origin/<your-branch-name> git rebase origin/<your-branch-name>
``` ```
2. After rebasing, force-push new changes to your fork: 1. After rebasing, force-push new changes to your fork:
```bash ```shell
git push --force-with-lease origin <your-branch-name> git push --force-with-lease origin <your-branch-name>
``` ```
#### Merge conflicts and rebasing #### Merge conflicts and rebasing
{{< note >}} {{< note >}}
For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help. For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts),
[Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the
`#sig-docs` Slack channel for help.
{{< /note >}} {{< /note >}}
If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR. If another contributor commits changes to the same file in another PR, it can create a merge
conflict. You must resolve all merge conflicts in your PR.
1. Update your fork and rebase your local branch: 1. Update your fork and rebase your local branch:
```bash ```shell
git fetch origin git fetch origin
git rebase origin/<your-branch-name> git rebase origin/<your-branch-name>
``` ```
Then force-push the changes to your fork: Then force-push the changes to your fork:
```bash ```shell
git push --force-with-lease origin <your-branch-name> git push --force-with-lease origin <your-branch-name>
``` ```
2. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch: 1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch:
```bash ```shell
git fetch upstream git fetch upstream
git rebase upstream/main git rebase upstream/main
``` ```
3. Inspect the results of the rebase: 1. Inspect the results of the rebase:
```bash ```shell
git status git status
``` ```
This results in a number of files marked as conflicted. This results in a number of files marked as conflicted.
4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker. 1. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`.
Resolve the conflict and delete the conflict marker.
{{< note >}} {{< note >}}
For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
{{< /note >}} {{< /note >}}
5. Add the files to the changeset: 1. Add the files to the changeset:
```bash ```shell
git add <filename> git add <filename>
``` ```
6. Continue the rebase:
```bash 1. Continue the rebase:
git rebase --continue
```
7. Repeat steps 2 to 5 as needed. ``
git rebase --continue
```
After applying all commits, the `git status` command shows that the rebase is complete. 1. Repeat steps 2 to 5 as needed.
8. Force-push the branch to your fork: After applying all commits, the `git status` command shows that the rebase is complete.
```bash 1. Force-push the branch to your fork:
git push --force-with-lease origin <your-branch-name>
```
The pull request no longer shows any conflicts. ```shell
git push --force-with-lease origin <your-branch-name>
```
The pull request no longer shows any conflicts.
### Squashing commits ### Squashing commits
{{< note >}} {{< note >}}
For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help. For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History),
or ask in the `#sig-docs` Slack channel for help.
{{< /note >}} {{< /note >}}
If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally. If your PR has multiple commits, you must squash them into a single commit before merging your PR.
You can check the number of commits on your PR's **Commits** tab or by running the `git log`
command locally.
{{< note >}} {{< note >}}
This topic assumes `vim` as the command line text editor. This topic assumes `vim` as the command line text editor.
@@ -512,79 +545,83 @@ This topic assumes `vim` as the command line text editor.
1. Start an interactive rebase: 1. Start an interactive rebase:
```bash ```shell
git rebase -i HEAD~<number_of_commits_in_branch> git rebase -i HEAD~<number_of_commits_in_branch>
``` ```
Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase. Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively.
`HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase.
Output is similar to: Output is similar to:
```bash ```none
pick d875112ca Original commit pick d875112ca Original commit
pick 4fa167b80 Address feedback 1 pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2 pick 7d54e15ee Address feedback 2
# Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands) # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
... ...
# These lines can be re-ordered; they are executed from top to bottom. # These lines can be re-ordered; they are executed from top to bottom.
``` ```
The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word `pick` changes the status of the commit once the rebase is complete. The first section of the output lists the commits in the rebase. The second section lists the
options for each commit. Changing the word `pick` changes the status of the commit once the rebase
is complete.
For the purposes of rebasing, focus on `squash` and `pick`. For the purposes of rebasing, focus on `squash` and `pick`.
{{< note >}} {{< note >}}
For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode).
{{< /note >}} {{< /note >}}
2. Start editing the file. 1. Start editing the file.
Change the original text: Change the original text:
```bash ```none
pick d875112ca Original commit pick d875112ca Original commit
pick 4fa167b80 Address feedback 1 pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2 pick 7d54e15ee Address feedback 2
``` ```
To: To:
```bash ```none
pick d875112ca Original commit pick d875112ca Original commit
squash 4fa167b80 Address feedback 1 squash 4fa167b80 Address feedback 1
squash 7d54e15ee Address feedback 2 squash 7d54e15ee Address feedback 2
``` ```
This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into
`d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline.
3. Save and exit your file. 1. Save and exit your file.
4. Push your squashed commit: 1. Push your squashed commit:
```bash ```shell
git push --force-with-lease origin <branch_name> git push --force-with-lease origin <branch_name>
``` ```
## Contribute to other repos ## Contribute to other repos
The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments. The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these
repositories contain documentation: user-facing help text, error messages, API references or code
comments.
If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization. If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes
This can help you figure out where to submit your issue or PR. organization. This can help you figure out where to submit your issue or PR.
Each repository has its own processes and procedures. Before you file an Each repository has its own processes and procedures. Before you file an issue or submit a PR,
issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and read that repository's `README.md`, `CONTRIBUTING.md`, and `code-of-conduct.md`, if they exist.
`code-of-conduct.md`, if they exist.
Most repositories use issue and PR templates. Have a look through some open Most repositories use issue and PR templates. Have a look through some open issues and PRs to get
issues and PRs to get a feel for that team's processes. Make sure to fill out a feel for that team's processes. Make sure to fill out the templates with as much detail as
the templates with as much detail as possible when you file issues or PRs. possible when you file issues or PRs.
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
- Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process. - Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process.