Skip to content

Latest commit

 

History

History
59 lines (38 loc) · 2.73 KB

create_pull_request.md

File metadata and controls

59 lines (38 loc) · 2.73 KB
Raw

Create pull request

We’re excited that you want to join us. This doc explains the process for create a pull request to the Kindling project. ​

Before you submit a pull request

Fist-time contributors shuld read the Contributor Guide to get started. Make sure your pull request adheres to relevant code conventions.

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. 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 Commit Message Guidelins
  • 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 # or Fixes #.
  • To avoid regressions, the pull request should include tests that replicate the fixed bug.

Run Local Verifications

You must run local verifications before you submit your pull request.

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 to learn more about code reviews. ​

Commit Message Guidelines

Git commit message is the best way to communicate context about a change to fellow developers. Git commit message should accurately describe both what and why it is being done. Commit Messages are usually comprised of two parts: subject and body. Subject and body content should better follow these guides most of which follow kubernetes commit message guidelines:

  • Separate subject from body with a blank line
  • Subject start with area tag
  • Limit the subject line to 50 characters
  • Do not end the subject line with a period
  • Wrap the body at 72 characters
  • Use the imperative mood in the subject line
  • Use the body to explain what and whyof this commit ​

Here is a git commit message example : agent: add tcp packet drop metric

Enhance the ablity of identifying tcp layer problem ​