mirror of
https://github.com/kubevela/kubevela.git
synced 2026-05-27 11:48:23 +00:00
046376aa1a
* refine our contribute guides * Update CONTRIBUTING.md Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com> Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>
87 lines
4.0 KiB
Markdown
87 lines
4.0 KiB
Markdown
# Create a pull request
|
|
|
|
We're excited that you're considering making a contribution to the KubeVela project!
|
|
This document guides you through the process of creating a [pull request](https://help.github.com/en/articles/about-pull-requests/).
|
|
|
|
## Before you begin
|
|
|
|
We know you're excited to create your first pull request. Before we get started, read these resources first:
|
|
|
|
- Learn how to start [Contributing to KubeVela](/CONTRIBUTING.md).
|
|
- Make sure your code follows the relevant [style guides](/contribute/style-guides).
|
|
|
|
## Your first pull request
|
|
|
|
If this is your first time contributing to an open-source project on GitHub, make sure you read about [Creating a pull request](https://help.github.com/en/articles/creating-a-pull-request).
|
|
|
|
To increase the chance of having your pull request accepted, make sure your pull request follows these guidelines:
|
|
|
|
- Title and description matches the implementation.
|
|
- Commits within the pull request follow the [Formatting guidelines](#Formatting-guidelines).
|
|
- The pull request closes one related issue.
|
|
- The pull request contains necessary tests that verify the intended behavior.
|
|
- If your pull request has conflicts, rebase your branch onto the main branch.
|
|
|
|
If the pull request fixes a bug:
|
|
|
|
- The pull request description must include `Closes #<issue number>` or `Fixes #<issue number>`.
|
|
- To avoid regressions, the pull request should include tests that replicate the fixed bug.
|
|
|
|
Please refer to the [code conventions](/contribute/coding-conventions.md) for better code style and conventions.
|
|
|
|
## Code review
|
|
|
|
Once you've created a pull request, the next step is to have someone review your change.
|
|
A review is a learning opportunity for both the reviewer and the author of the pull request.
|
|
|
|
If you think a specific person needs to review your pull request, then you can tag them in the description or in a comment.
|
|
Tag a user by typing the `@` symbol followed by their GitHub username.
|
|
|
|
We recommend that you read [How to do a code review](https://google.github.io/eng-practices/review/reviewer/) to learn more about code reviews.
|
|
|
|
## Formatting guidelines
|
|
|
|
A well-written pull request minimizes the time to get your change accepted.
|
|
These guidelines help you write good commit messages and descriptions for your pull requests.
|
|
|
|
### Commit message format
|
|
|
|
KubeVela uses the guidelines for commit messages outlined in [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/), with the following additions:
|
|
|
|
- Subject line must begin with the _area_ of the commit.
|
|
- A footer in the form of an optional [keyword and issue reference](https://help.github.com/en/articles/closing-issues-using-keywords).
|
|
|
|
#### Area
|
|
|
|
The area should use upper camel case, e.g. UpperCamelCase.
|
|
|
|
Prefer using one of the following areas:
|
|
|
|
- **Application:** Changes to the application controller.
|
|
- **Component:** Changes to the component related code or definition controller.
|
|
- **Trait:** Changes to the trait related code or definition controller.
|
|
- **CUE:** Changes to the CUE related logic.
|
|
- **Docs:** Changes to documentation.
|
|
- **AppConfig:** Changes to AppConfig related code.
|
|
|
|
**Examples**
|
|
|
|
- `Application: Support workflow in application controller`
|
|
- `CUE: Fix patch parse issues`
|
|
- `Docs: Changed url to URL in all documentation files`
|
|
|
|
### Pull request titles
|
|
|
|
The KubeVela team _squashes_ all commits into one when we accept a pull request.
|
|
The title of the pull request becomes the subject line of the squashed commit message.
|
|
We still encourage contributors to write informative commit messages, as they become a part of the Git commit body.
|
|
|
|
We use the pull request title when we generate change logs for releases. As such, we strive to make the title as informative as possible.
|
|
|
|
Make sure that the title for your pull request uses the same format as the subject line in the commit message.
|
|
|
|
### Pass all the CI checks
|
|
|
|
Before merge, All test CI should pass green.
|
|
The `codecov/project` should also pass. This means the coverage should not drop. See [Codecov commit status](https://docs.codecov.io/docs/commit-status#project-status).
|