Skip to content

Latest commit

 

History

History
51 lines (35 loc) · 2.45 KB

pull-requests.md

File metadata and controls

51 lines (35 loc) · 2.45 KB

Pull Requests

Changes to any main codebase - master branch in Git repository, for example - must be done using pull requests (PR).

Pull requests enable:

  • Code inspection - see Code Reviews
  • Running automated qualification of the code
    • Linters
    • Compilation
    • Unit tests
    • Integration tests etc.

The requirements of pull requests can and should be enforced by policies, which can be set in the most modern version control and work item tracking systems. See Evidence and Measures section for more information.

General Process

  1. Implement changes based on the well-defined description and acceptance criteria of the task at hand
  2. Then, before creating a new pull request:
    • Make sure the code conforms with the agreed coding conventions
      • This can be partially automated using linters
    • Ensure the code compiles and runs without errors or warnings
    • Write and/or update tests to cover the changes and make sure all new and existing tests pass
    • Write and/or update the documentation to match the changes
  3. Once convinced the criteria above are met, create and submit a new pull request adhering to the pull request template
  4. Follow the code review process to merge the changes to the main codebase

Size Guidance

We should always aim to have pull requests be as small as possible, without losing context and technical feasibility. Small PRs have multiple advantages:

  1. They are easier to review; a clear benefit for the reviewers.
  2. They are easier to deploy; this is aligned with the strategy of release fast and release often.
  3. Minimizes possible conflicts and stale PRs, which are difficult to merge and keep in sync with master either because they're very dynamic or contain refactoring.

However, we should avoid having PRs that include code that is without context or loosely coupled.

Resources