Skip to content

Commits, branches, and merging

Commits

This project enforces the Conventional Commits style for commit message formatting:

<type>[(optional-scope)]: <description>

[optional body]

Where <type> indicates the nature of the commit, one of a list of possible values:

  • build - related to the build or compile process
  • chore - administrative tasks, cleanups, dev environment
  • ci - related to automated builds/tests etc.
  • docs - updates to the documentation
  • feat - new code, features, or interfaces
  • fix - bug fixes
  • perf - performance improvements
  • refactor - non-breaking logic refactors
  • revert - undo a prior change
  • style - code style and formatting
  • test - having to do with testing of any kind

E.g.

git commit -m "feat(eligibility/urls): add path for start"

Branches

The default GitHub branch is main. All new feature work should be in the form of Pull Requests (PR) that target main as their base.

In addition to main, the repository has three other long-lived branches:

  • test and prod are read-only (no longer actively used) and correspond to the Test and Production deploy environments, respectively. The last release using these branches was 2024.07.1.
  • gh-pages hosts the compiled documentation, and is always forced-pushed by the docs build process.

Protection rules

Branch protection rules are in place on main to:

  • Prevent branch deletion
  • Restrict force-pushing, where appropriate
  • Require passing status checks before merging into the target branch is allowed

Branch protection rules are in place on test and prod to:

  • Prevent branch deletion
  • Lock the branch, making it read-only so that users cannot push to the branch since the branch is no longer used

PR branches

PR branches are typically named with a conventional type prefix, a slash /, and then descriptor in lower-dashed-case:

<type>/<lower-dashed-descriptor>

E.g.

git checkout -b feat/flow-multi-select

and

git checkout -b refactor/flow-model

PR branches are deleted once their PR is merged.

Merging

Merging of PRs should be done using the merge commit strategy. The PR author should utilize git rebase -i to ensure their PR commit history is clean, logical, and free of typos.

When merging a PR into main, it is customary to format the merge commit message like:

Title of PR (#number)

instead of the default:

Merge pull request #number from source-repo/source-branch