Git Branching Workflow
Standardized Git branch creation, naming conventions, and lifecycle hygiene for Apple platform and mobile engineering teams.
Contents
Trigger Boundary
Use this skill when creating branches for new features, bug fixes, refactoring, emergency hotfixes, or release preparation. Use it to establish consistent branch names and isolate work units before opening pull requests.
Do not use this skill for resolving complex three-way merge conflicts, debugging git index corruptions, or configuring low-level git hooks.
Branch Naming Taxonomy
Branch names must be lowercase, hyphen-separated (kebab-case), and prefixed by type:
| Prefix |
Scope |
Example |
feat/ |
New user-facing feature or architecture capability |
feat/apple-pay-checkout |
fix/ |
Bug fix during development or QA cycles |
fix/dark-mode-contrast |
refactor/ |
Code reorganization without changing observable behavior |
refactor/modularize-network-layer |
perf/ |
Performance optimization, memory leak fix, launch time |
perf/table-view-prefetching |
test/ |
Adding unit tests, UI tests, benchmarks, or eval suites |
test/storekit-purchase-evals |
release/ |
Version bump, metadata freeze, and release candidate staging |
release/v1.3.0 |
hotfix/ |
Critical production patch branched directly from production base |
hotfix/crash-on-launch-ios26 |
chore/ |
Tooling, dependency updates, CI/CD pipeline changes |
chore/update-fastlane-actions |
When tracking a project management or issue tracker ticket, place the ticket key immediately after the prefix:
feat/IOS-1042-biometric-auth
fix/CORE-89-keychain-migration
Branch Lifecycle Rules
- Always branch from up-to-date base: Fetch remote state (
git fetch origin) before branching off origin/main (or origin/develop). Never branch off stale local tracking branches.
- Single responsibility: One branch must address one conceptual deliverable. Do not combine feature work with broad cleanup or unrelated refactors.
- Short-lived branches: Keep feature branches short-lived (1–3 days). Integrate changes incrementally to prevent massive merge divergence.
- Clean commit history: Group commits logically with imperative commit titles (
feat: add passkey enrollment coordinator). Avoid intermediate commit noise ("wip", "fix typo") before final merge.
- Protected base branches: Never commit directly to
main or release branches. All integrations must pass CI verification via pull request.
Standard Commands
Create Feature Branch
git fetch origin
git checkout -b feat/passkey-enrollment origin/main
Create Production Hotfix
git fetch origin
git checkout -b hotfix/expired-auth-token origin/main
Sync Feature Branch with Base (Rebase)
git fetch origin
git rebase origin/main
Delete Branch After Merge
git branch -d feat/passkey-enrollment
git push origin --delete feat/passkey-enrollment
AI Agent Branch Isolation
When an AI agent is tasked with building a feature or executing a migration:
- Check out a dedicated branch (
feature/ or feat/) before making filesystem changes.
- Never perform destructive edits or broad refactoring on
main.
- Verify that untracked or scratch files do not pollute the git working directory before opening a pull request.
Common Mistakes
- Ambiguous or generic branch names: Using
temp, test, my-work, or fix-bug without domain context.
- Branching from stale local refs: Creating a branch without running
git fetch origin first, causing old base commit divergence.
- Scope creep: Adding feature work into a branch named
fix/... or mixing architecture rewrites into a bugfix branch.
- Using uppercase or snake_case: Naming branches
Feat/NewUI or fix/crash_issue instead of feat/new-ui and fix/crash-issue.
- Rebasing public shared branches: Rebasing branches where multiple developers collaborate, causing commit history rewrites.
Review Checklist
References
- Branch Conventions and Lifecycle — Comprehensive guide on branching strategies, PR workflows, CI/CD trigger automation, and team hygiene.
1---2name: git-branching-workflow3description: Standardized Git branch creation, naming taxonomies (feat/, fix/, refactor/, hotfix/, release/, chore/), trunk-based integration, and PR isolation lifecycles. Use when creating branches, preparing pull requests, or standardizing team git workflows; do not use for resolving merge conflicts or low-level git plumbing.4---56# Git Branching Workflow78Standardized Git branch creation, naming conventions, and lifecycle hygiene for Apple platform and mobile engineering teams.910## Contents1112- [Trigger Boundary](#trigger-boundary)13- [Branch Naming Taxonomy](#branch-naming-taxonomy)14- [Branch Lifecycle Rules](#branch-lifecycle-rules)15- [Standard Commands](#standard-commands)16- [AI Agent Branch Isolation](#ai-agent-branch-isolation)17- [Common Mistakes](#common-mistakes)18- [Review Checklist](#review-checklist)19- [References](#references)2021## Trigger Boundary2223Use this skill when creating branches for new features, bug fixes, refactoring, emergency hotfixes, or release preparation. Use it to establish consistent branch names and isolate work units before opening pull requests.2425Do not use this skill for resolving complex three-way merge conflicts, debugging git index corruptions, or configuring low-level git hooks.2627## Branch Naming Taxonomy2829Branch names must be lowercase, hyphen-separated (kebab-case), and prefixed by type:3031| Prefix | Scope | Example |32|---|---|---|33| `feat/` | New user-facing feature or architecture capability | `feat/apple-pay-checkout` |34| `fix/` | Bug fix during development or QA cycles | `fix/dark-mode-contrast` |35| `refactor/` | Code reorganization without changing observable behavior | `refactor/modularize-network-layer` |36| `perf/` | Performance optimization, memory leak fix, launch time | `perf/table-view-prefetching` |37| `test/` | Adding unit tests, UI tests, benchmarks, or eval suites | `test/storekit-purchase-evals` |38| `release/` | Version bump, metadata freeze, and release candidate staging | `release/v1.3.0` |39| `hotfix/` | Critical production patch branched directly from production base | `hotfix/crash-on-launch-ios26` |40| `chore/` | Tooling, dependency updates, CI/CD pipeline changes | `chore/update-fastlane-actions` |4142When tracking a project management or issue tracker ticket, place the ticket key immediately after the prefix:43- `feat/IOS-1042-biometric-auth`44- `fix/CORE-89-keychain-migration`4546## Branch Lifecycle Rules47481. **Always branch from up-to-date base**: Fetch remote state (`git fetch origin`) before branching off `origin/main` (or `origin/develop`). Never branch off stale local tracking branches.492. **Single responsibility**: One branch must address one conceptual deliverable. Do not combine feature work with broad cleanup or unrelated refactors.503. **Short-lived branches**: Keep feature branches short-lived (1–3 days). Integrate changes incrementally to prevent massive merge divergence.514. **Clean commit history**: Group commits logically with imperative commit titles (`feat: add passkey enrollment coordinator`). Avoid intermediate commit noise ("wip", "fix typo") before final merge.525. **Protected base branches**: Never commit directly to `main` or release branches. All integrations must pass CI verification via pull request.5354## Standard Commands5556### Create Feature Branch57```bash58git fetch origin59git checkout -b feat/passkey-enrollment origin/main60```6162### Create Production Hotfix63```bash64git fetch origin65git checkout -b hotfix/expired-auth-token origin/main66```6768### Sync Feature Branch with Base (Rebase)69```bash70git fetch origin71git rebase origin/main72```7374### Delete Branch After Merge75```bash76git branch -d feat/passkey-enrollment77git push origin --delete feat/passkey-enrollment78```7980## AI Agent Branch Isolation8182When an AI agent is tasked with building a feature or executing a migration:83- Check out a dedicated branch (`feature/` or `feat/`) before making filesystem changes.84- Never perform destructive edits or broad refactoring on `main`.85- Verify that untracked or scratch files do not pollute the git working directory before opening a pull request.8687## Common Mistakes8889- **Ambiguous or generic branch names**: Using `temp`, `test`, `my-work`, or `fix-bug` without domain context.90- **Branching from stale local refs**: Creating a branch without running `git fetch origin` first, causing old base commit divergence.91- **Scope creep**: Adding feature work into a branch named `fix/...` or mixing architecture rewrites into a bugfix branch.92- **Using uppercase or snake_case**: Naming branches `Feat/NewUI` or `fix/crash_issue` instead of `feat/new-ui` and `fix/crash-issue`.93- **Rebasing public shared branches**: Rebasing branches where multiple developers collaborate, causing commit history rewrites.9495## Review Checklist9697- [ ] Branch name strictly adheres to `<prefix>/<kebab-case-description>` or `<prefix>/<TICKET>-<description>`.98- [ ] Branch was created from the latest remote base (`origin/main` or `origin/develop`).99- [ ] Branch changes match the declared prefix scope (no feature code in a `fix/` branch).100- [ ] No extraneous files (`.DS_Store`, build artifacts, temporary scratch scripts) are tracked.101- [ ] Branch is rebased onto the target base branch before opening PR.102103## References104105- [Branch Conventions and Lifecycle](references/branch-conventions.md) — Comprehensive guide on branching strategies, PR workflows, CI/CD trigger automation, and team hygiene.