Skip to content

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.

PatternPurposeExample
mainDefault branchmain
feat/ISSUE-ID-short-descriptionNew feature workfeat/ABC-123-dashboard-filters
fix/ISSUE-ID-short-descriptionBug fixesfix/ABC-456-null-guard
hotfix/ISSUE-ID-short-descriptionUrgent production fixhotfix/ABC-789-login-outage
release/vX.Y.ZRelease branchrelease/v1.2.0
chore/ISSUE-ID-short-descriptionMaintenance workchore/ABC-321-deps-refresh

Why this matters

Clear branch names communicate intent and keep issues traceable during review and release work.

Commits

text
feat(api): add pagination to project list
fix(ui): prevent null avatar crash
chore(deps): bump vitepress to latest

Why 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.state inference
  • Update tests
  • Documentation updated
  • Project runs locally
  • Tests pass locally