Skip to content

Latest commit

 

History

History
52 lines (37 loc) · 2.58 KB

contributing.md

File metadata and controls

52 lines (37 loc) · 2.58 KB

How to Contribute

Linting and Formatting

GitHub will run linting and formatting check.

To automatically fix what it finds, run npx nx format:write.

Best Practices

Development Workflow

We use a modifed version of GitFlow.

  • "feature branches" have a specific prefix:
    • feat/ for features and updates
    • fix/ for bugfixes and hotfixes
    • refactor/ for large internal changes
    • style/ for code style changes (white-space, formatting, etc.)
    • chore/ for no-op changes
    • docs/ for documentation
    • perf/ for performance improvements
    • test/ for test case updates
    • or other "types" from Conventional Commits
  • "develop" branch is usually main,
    but can exist as a long-lived multi-task branch
  • "release branches" (as needed) are prefixed with release/
  • "hotfix branches" are prefixed fix/
  • "master branch" is always main

Release Workflow

Only appointed team members may release versions.

  1. Create release or pre-release and tag on GitHub.

    type use case tag format example
    release deploy to prod. vA.B.C following SemVer v1.1.3
    pre-release deploy to dev. vA.B.C-YYYYMM-ZZ
    Where ZZ is the number of pre-releases since vA.B.C.
    v1.1.3-202312-03
    Where 03 is the third pre-release of December.
  2. If a pre-release is off of a dev branch, i.e. has code from branches of un-merged PRs, then add those PRs to the changelog e.g.

    - feat: TUP-631 migrate blog page css to core-cms by @wesleyboar in #385 at b7f6651
    - TUP-609 Improve feedback when users reply to tickets by @sophia-massie in #382 at 53cd648

    (The at 123abc0 refers to the commit at which the PR's branch was merged.)