Working with Git
Consistent Git practices make work easy to review, trace, and ship.
Branch naming conventions
Use descriptive, issue-linked branches so intent is clear at a glance.
| Pattern | Purpose | Example |
|---|---|---|
main | Default branch | main |
feat/ISSUE-ID-short-description | New feature work | feat/ABC-123-dashboard-filters |
fix/ISSUE-ID-short-description | Bug fixes | fix/ABC-456-null-guard |
hotfix/ISSUE-ID-short-description | Urgent production fix | hotfix/ABC-789-login-outage |
release/vX.Y.Z | Release branch | release/v1.2.0 |
chore/ISSUE-ID-short-description | Maintenance work | chore/ABC-321-deps-refresh |
Why this matters
Clear branch names communicate intent and keep issues traceable during review and release work.
Commits
- Keep commits single responsibility.
- Use Conventional Commits (cheatsheet).
- Keep messages focused on intent and impact.
feat(api): add pagination to project list
fix(ui): prevent null avatar crash
chore(deps): bump vitepress to latestWhy this matters
Small, focused commits make the history easier to scan, revert, and audit.
Merge requests
- Use project-provided templates whenever available.
- Title format:
ISSUE-ID: Short Description of the Task. - Own splitting your ticket into reviewable pieces.
- Keep merge requests small and easy to review.
- Create the MR as soon as development starts; set it to draft and assign a reviewer.
- Maintain a checklist in the MR description and check items as you build.
- Undraft only when work is complete and the project runs with tests passing.
- Keep descriptions clear and descriptive.
- Disclose the magnitude of AI usage (see AI Usage).
- Aim to close issues started that day before the day ends.
Why keep merge requests small
Large MRs are easy to skim past, and it is harder to keep a reliable mental map of changes.
Why start MRs early
Draft MRs promote transparency and give POs and reviewers time to plan their review schedule.
Why close issues daily
Closing issues daily builds planning discipline, supports smaller MRs, and encourages early communication when work takes longer.
Why this matters
Small, early, and transparent MRs reduce review fatigue, help the team plan, and keep the main branch moving.
Example MR checklist
- Add state field to
ContractDTO - Implement a procedure for
contract.stateinference - Update tests
- Documentation updated
- Project runs locally
- Tests pass locally