Branching Strategy

SeedTrust uses a two-branch model: dev as the integration branch and main as the production branch.

Branches

Branch	Purpose
`main`	Production. Only receives merges at sprint release or via hotfix.
`dev`	Integration. All feature work merges here first.

Feature Development

Branch from dev:

git checkout dev
git pull
git checkout -b feat/ST-xxxx

Do your work, open a PR targeting dev.
After review and merge, the feature is in dev and will go out with the next sprint release.

At the end of each sprint, dev is merged into main and a release is cut.

Hotfixes

For urgent fixes that can’t wait for the next sprint:

Branch from main:

git checkout main
git pull
git checkout -b hotfix/ST-xxxx

Fix.
Merge into dev to validate in the testing environment (safe — the fix came from main):
Terminal window
```
git checkout dev
git merge hotfix/ST-xxxx
```
Once validated, open a PR targeting main.
After merge, release from main.
Merge main back into dev to keep branches in sync:
Terminal window
```
git checkout dev
git merge main
```

Highest-Priority Tickets

If a Jira ticket has Highest priority, treat it exactly like a hotfix regardless of ticket type — branch from main so it can reach production without waiting for dev to stabilize.

Environments: testing mirrors dev; production mirrors main. There is no dedicated staging environment that mirrors main, so validate in testing by merging your branch into dev first (safe — the fix came from main so it carries no unrelated dev changes).

Branch from main:

git checkout main
git pull
git checkout -b hotfix/ST-xxxx

Fix.
Merge into dev to validate in the testing environment:
Terminal window
```
git checkout dev
git merge hotfix/ST-xxxx
```
Once validated, open a PR targeting main.
After merge, release from main.
Merge main back into dev to keep branches in sync:
Terminal window
```
git checkout dev
git merge main
```

Do not branch from dev for these tickets, even if related work is already there — that would tie the release to untested changes.

Flow at a Glance

feat/my-feature         ────►  dev  ──►  main   (sprint release)
hotfix/my-fix           ──────────►  main  ──►  dev  (sync back)
ST-XXXX (Highest prio)  ──────────►  main  ──►  dev  (treated as hotfix)

Branch Naming

Type	Pattern	Example
Feature	`feat/<ticket-number>`	`feat/ST-1234`
Hotfix	`hotfix/<ticket-number>`	`hotfix/ST-2345`

Commit Messages

Every commit must include the Jira ticket number and follow Conventional Commits format so changes can be traced and changelogs can be generated automatically.

Format: ST-XXXX type(scope): description

Part	Description
`ST-XXXX`	Jira ticket number — required on all commits
`type`	What kind of change (see table below)
`(scope)`	Area of the codebase affected — optional but recommended
`description`	Short, lowercase, no period at the end

Commit types:

Type	Use for
`feat`	New feature
`fix`	Bug fix
`refactor`	Code change that is neither a feature nor a fix
`docs`	Documentation only
`test`	Adding or updating tests
`chore`	Maintenance, dependency bumps, config
`style`	Formatting, whitespace (no logic change)
`perf`	Performance improvement

Examples:

ST-1234 feat(disbursements): add surrogate payment approval step
ST-2345 fix(banking): fix ACH form validation on case creation
ST-3675 fix(funding): fix total remainder and estimated to fund
ST-3644 feat(banking): add huntington balance summary endpoint
ST-3763 fix(nacha): atomize comp and transaction writes in batch

Commits without a ticket (merge fixes, chores, docs):

fix(case): restore css and js lost in bad merge with main
chore(deps): bump lodash to 4.17.21
docs(branching): add conventional commits guidance

Use the same ticket number as your branch
Keep the description lowercase, present tense
No period at the end