Commits, branches, and merging ¶
This project enforces the Conventional Commits style for commit message formatting:
<type>[(optional-scope)]: <description> [optional body]
<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
git commit -m "feat(eligibility/urls): add path for start"
The default GitHub branch is
dev. All new feature work should be in the form of Pull Requests (PR) that target
dev as their
In addition to
dev, the repository has three other long-lived branches:
prodcorrespond to the Test and Production deploy environments, respectively.
gh-pageshosts the compiled documentation, and is always forced-pushed by the docs build process.
Protection rules ¶
Branch protection rules are in place on three environment branches (
- Prevent branch deletion
- Restrict force-pushing, where appropriate
- Require passing status checks before merging into the target branch is allowed
PR branches ¶
PR branches are typically named with a conventional type prefix, a slash
/, and then descriptor in
git checkout -b feat/verifier-radio-buttons
git checkout -b refactor/verifier-model
PR branches are deleted once their PR is merged.
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
dev, 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