Skip to content

Instantly share code, notes, and snippets.

@aymanalhattami

aymanalhattami/GitPullRequestPractices.md

Forked from Aditi3/GitPullRequestPractices.md
Created February 4, 2025 18:09
Show Gist options
  • Save aymanalhattami/52685c9c2e501024f956a2ed5ff7f649 to your computer and use it in GitHub Desktop.
Save aymanalhattami/52685c9c2e501024f956a2ed5ff7f649 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
GitPullRequestPractices.md

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