Skip to main content

Commit and PR guidelines

Commit message formatting​

If you'd like, prefix your commit message with one of the following types (borrowed from semantic/Angular conventions):

  • build: Changes that affect the build system or external dependencies (example scopes: NPM, Docker, codegen)
  • devops: Changes to our CI, deployment, or configuration files and scripts (example scopes: Render, environment variables, GitHub Actions)
  • docs: Documentation-only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • revert: A code change that reverts a previous change; ideally, reference the specific change being reverted
  • style: A code change that is focused on improving UI/UX or implementing design
  • test: Adding missing tests or correcting existing tests

Since we squash PRs into develop, individual commit titles are mainly visible to your coworkers and not prominent in the commit history over the longterm.

Pull requests​

All PRs should be backed by a ticket.

Into develop (most feature development)​

When you pull request into develop, please squash and commit. Why?

  • Your code will land as a single commit to the develop branch, named after the PR's title, allowing for a cleaner history.
  • The history of your individual commits will be added to the description of that PR, allowing for traceability.
  • The history of your individual commits is kept (albeit separately) and is also available in the PR itself.

PRs should always start with a Linear issue number and short description (e.g. "KEY-1: Implemented x, fixed y").

Into production​

Only the develop branch should be PR'd into production. When you pull request into production, please merge and commit. Why?

  • Squashing and rebasing aren't effective because they create new commits on production that aren't the same as the history in develop. (Rebasing creates new commits, with new hashes, despite having the same diff.) This causes the two branches to diverge.
  • While we appreciate a linear history, it's more important that production reflects a slightly-behind version of what is on develop, and not a separate history.

Use and follow instructions in the Make a production PR template to make production PRs.

Production PRs generally do not need to be reviewed.