Code Review Guide

Code Review Guide

This guide is meant to facilitate Submariner code review by sharing norms, best practices, and useful patterns.

Submariner follows the Kubernetes Code Review Guide wherever relevant. This guide collects the most important highlights of the K8s process and adds Submariner-specific extensions.

Two non-author approvals required

Pull Requests to Submariner require two non-author code review approvals.

At least one approval must be from a Committer to the relevant part of the code base, as defined by the CODEOWNERS file at the root of the repository.

No merge commits

Kubernetes recommends avoiding merge commits.

Use git fetch and git rebase to avoid them.

Squash/amend commits into discrete steps

Kubernetes recommends squashing commits using these guidelines.

After a review, prepare your PR for merging by squashing your commits.

All commits left on your branch after a review should represent meaningful milestones or units of work. Use commits to add clarity to the development and review process.

Before merging a PR, squash the following kinds of commits:

  • Fixes/review feedback
  • Typos
  • Merges and rebases
  • Work in progress
  • Aim to have every commit in a PR compile and pass tests independently if you can, but it’s not a requirement.

Commit message formatting

Kubernetes recommends these commit message practices.

In summary:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs how