Not standardized. Read (internal) Formatting & Linting.
We use a modifed version of GitFlow.
- "feature branches" have a specific prefix:
feat/
for features and updatesfix/
for bugfixes and hotfixesrefactor/
for large internal changesstyle/
for code style changes (white-space, formatting, etc.)chore/
for no-op changesdocs/
for documentationperf/
for performance improvementstest/
for test case updates- or other "types" from Conventional Commits
- "develop" branch is usually
main
,
but can exist as a long-lived multi-feature branch prefixed withdev/
- "release branches" (as needed) are prefixed with
release/
- "hotfix branches" are prefixed
fix/
- "master branch" is always
main
Only appointed team members may release versions.
- (one time) Login to npm via:
npm login
- Create new branch for version bump.
- Verify build is up-to-date:
npm run build:css
Commit substantial unexpected changes via independent PR. - Update
CHANGELOG.md
. - Update version via:
npm version vN.N.N
(whereN.N.N
is the version tag) - Build with new version:
npm run build:css
- Commit, push, PR, review, merge.
- Publish to NPM via:
npm publish --access public
Project build will automatically occur before publish. - Create release and tag on GitHub.
- Fetch the latest tags.
git fetch --tags
- Check whether tag is annotated.
git describe --always
(expectvN.N.N
i.e. the version tag) - If tag is not annotated, then:
- Annotate Github's tag:
bin/annotate-tag.sh vN.N.N
(whereN.N.N
is the version tag) - Overwrite remote tag with annotated one:
git push --tags --force
- Annotate Github's tag: