Warning

🚧 Work in Progress: This page is currently under construction. Content may be incomplete or subject to change. To contribute, see the contribution guide.

Git Workflow

---

Branching strategy

The Technology department follows a trunk-based development approach with short-lived feature branches.

main  ──────────────────────────────────────────────►  (always deployable)
         ↑           ↑              ↑
    feature/xxx   fix/yyy       docs/zzz
   (short-lived) (short-lived) (short-lived)

Branch type	Pattern	Purpose	Merges into
Feature	feature/short-description	New functionality	main
Bug fix	fix/short-description	Bug fix (non-urgent)	main
Hotfix	hotfix/short-description	Urgent production fix	main (then tag)
Documentation	docs/short-description	Documentation only	main
Release	release/v1.2.0	Release stabilization (if needed)	main

---

Commit message convention

Follow the Conventional Commits specification:

<type>(<scope>): <short description>

[optional body]

[optional footer]

Types:

Type	When to use
feat	New feature
fix	Bug fix
docs	Documentation only
refactor	Code change that neither fixes a bug nor adds a feature
test	Adding or fixing tests
chore	Build process, dependencies, tooling
perf	Performance improvement
ci	CI/CD configuration changes

Examples:

feat(data): add daily NAV ingestion DAG for PE fund
 
fix(api): handle null reference_date in capital calls endpoint
 
docs(runbook): update BigQuery start-stop procedure
 
chore(deps): upgrade airflow to 2.9.1

---

Pull Request process

1. Open a PR from your feature branch to main
2. Fill in the PR template (description, what changed, how to test)
3. At least 1 approval required before merging (2 for changes to critical systems)
4. All CI checks must pass (lint, tests, security scan)
5. Squash and merge is preferred to keep main history clean
6. Delete the branch after merging

---

Code review guidelines

For authors:

• Keep PRs small and focused — one logical change per PR
• Write a clear description: what changed and why
• Link to the relevant ticket/issue

For reviewers:

• Review within 1 business day for normal PRs, 2 hours for hotfixes
• Focus on correctness, security, and maintainability — not style (that’s what linters are for)
• Approve with confidence or request changes with clear explanations