Skip to content

Instantly share code, notes, and snippets.

@Aditi3
Created July 11, 2023 14:49
Show Gist options
  • Select an option

  • Save Aditi3/a3078c3f9eda0855dd25da86bfa27032 to your computer and use it in GitHub Desktop.

Select an option

Save Aditi3/a3078c3f9eda0855dd25da86bfa27032 to your computer and use it in GitHub Desktop.

Pull request norms

  • It's recommended to divide PR into independently mergeable parts. This not only promotes simpler designs but also reduces coupling.
  • It's best to break down the PR into smaller related commits rather than having a single PR with many changes. Reviewers find it difficult to go through 50+ file changes in one go.
  • At least 1-2 developer approvals are required for a PR review, except for simple changes like typo fixes or documentation updates.
  • A well-written description of the PR is crucial for the reviewer to understand the code's purpose.
  • Additionally, PR labels can help to give a clearer picture of the PR's status or functionality.

Here's an example of a PR with related commit messages -

feat: add an XYZ support

test: add unit tests for an XYZ

docs: add documentation for an XYZ

Here's an example of a PR with unrelated commit messages(not recommended) -

feat: add an XYZ support

fix: add fix for ABC feature

refactor: refactor QPR feature code

It seems there is a lot happening and alterations have been made across various sections of the code base. It would be more effective to split up the commit messages into multiple PRs that focus on specific and relevant changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment