sqlitecpp-git-branching

# SQLiteCpp Git Branching ## When to create a branch - User mentions working on a task, issue, or feature. - User references a GitHub issue number. ## Before starting work 1. Run `git status` to check current branch. 2. If on `master` or wrong branch, create a task-specific branch from `master`. Create the branch before the first edit. If edits were accidentally made on `master`, create the task branch with the working tree intact before continuing. ## Branch naming - With issue: `<issue>-<type>-<short-description>` - `123-fix-short-description` - `123-feature-short-description` - Without issue: `<type>-<short-description>` - `fix-short-description` - `feature-short-description` - Issue ID is optional; do not use a `000-` prefix. ## Maintenance branch conventions - Updating the bundled SQLite3: `update-sqlite-X.Y.Z` (e.g. `update-sqlite-3.52.2`). See [[sqlitecpp-update-sqlite]]. - Cutting a release: `release-X.Y.Z`. See [[sqlitecpp-release]]. - Maintaining a released minor line: `sqlitecpp-X.Y.x` (e.g. `sqlitecpp-3.4.x`). Branch from the final release commit. Do not reuse an older major-line development branch such as `sqlitecpp-3.x`. ## Branch-only requests - If the user only requests a branch, create it and stop (no file changes).