kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #5779 from MadhavJivrajani/master 

Add documentaion for tide/squash-on-merge
This commit is contained in:
Kubernetes Prow Robot 2021-05-14 06:32:06 -07:00 committed by GitHub
parent ca0ca539c5 c4906d2ad9
commit 7795e2bd94
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contributors/guide/contributor-cheatsheet/README.md
View File

@ -374,7 +374,7 @@ git rebase -i HEAD~3
git push --force git push --force
``` ```
**Note**: you can also ask your reviewer to add the `tide/merge-method-squash` label to your PR (this can be done by a reviewer by issuing the command: `/label tide/merge-method-squash`), this will let the bot take care of squashing _all_ commits that are part of this PR and will not result in removal of the `LGTM` label (if already applied) or re-run of the CI tests.
[contributor guide]: /contributors/guide/README.md [contributor guide]: /contributors/guide/README.md
[developer guide]: /contributors/devel/README.md [developer guide]: /contributors/devel/README.md

2
contributors/guide/pull-requests.md
View File

@ -291,6 +291,8 @@ For more information, see [squash commits](./github-workflow.md#squash-commits).
Don't squash when there are independent changes layered to achieve a single goal. Don't squash when there are independent changes layered to achieve a single goal.
For instance, writing a code munger could be one commit, applying it could be another, and adding a precommit check could be a third. For instance, writing a code munger could be one commit, applying it could be another, and adding a precommit check could be a third.
One could argue they should be separate pull requests, but there's really no way to test/review the munger without seeing it applied, and there needs to be a precommit check to ensure the munged output doesn't immediately get out of date. One could argue they should be separate pull requests, but there's really no way to test/review the munger without seeing it applied, and there needs to be a precommit check to ensure the munged output doesn't immediately get out of date.
**Note**: you can also ask your reviewer to add the `tide/merge-method-squash` label to your PR (this can be done by a reviewer by issuing the command: `/label tide/merge-method-squash`), this will let the bot take care of squashing _all_ commits that are part of this PR and will not result in removal of the `LGTM` label (if already applied) or re-run of the CI tests.
## Commit Message Guidelines ## Commit Message Guidelines