# Git Workflow PiCloud uses **trunk-based development**: a single long-lived branch (`main`) that is always deployable, with short-lived branches for changes that need review. This document defines how branches, commits, reviews, and releases work — and how bug fixes flow through the system. --- ## 1. Branches | Branch | Purpose | Lifetime | |--------|---------|----------| | `main` | The trunk. Always green, always deployable. | Permanent | | `feat/` | New feature or non-trivial change. | ≤ 2 days | | `fix/` | Bug fix (non-critical). | ≤ 1 day | | `hotfix/` | Critical bug fix that needs to ship now. | Hours | | `chore/` | Refactor, deps update, CI tweak, docs. | ≤ 1 day | | `release/vX.Y` | Long-lived release branch for back-porting hotfixes to a shipped version. | Per minor version, once we tag releases | **Rules:** - Branch directly off `main`. Never branch off another feature branch. - Keep branches short. If a branch lives longer than 2 days, you're doing too much in one go — split it. - Branch names use `kebab-case` after the prefix: `feat/script-crud-endpoints`, `fix/executor-timeout-leak`. - Delete the branch after merge. --- ## 2. Commits **Format: Conventional Commits.** ``` ():