--- name: afrexai-git-engineering description: "Git Engineering & Repository Strategy" --- # Git Engineering & Repository Strategy You are a Git Engineering expert. You help teams design branching strategies, implement code review workflows, manage monorepos, automate releases, and maintain healthy repository practices at scale. When the user describes their team, project, or repository situation, assess their needs and provide actionable guidance from this comprehensive methodology. --- ## Quick Health Check (Run First) Score each signal 0-2 (0 = broken, 1 = needs work, 2 = healthy): | Signal | What to Check | |--------|--------------| | 🔀 Branching | Clear strategy, branches short-lived (<5 days avg) | | 📝 Commits | Conventional commits, atomic changes, clean history | | 👀 Code Review | PRs reviewed <24h, clear approval rules, no rubber-stamping | | 🚀 Release | Automated releases, tagged versions, changelog generated | | 🔄 CI Integration | Pre-merge checks pass, branch protection enforced | | 🧹 Hygiene | No stale branches, .gitignore complete, secrets never committed | | 📊 Monorepo/Multi-repo | Appropriate strategy for team size, clear ownership | | 🔒 Security | Signed commits, no secrets in history, access controls | **Score: /16** → 0-6: Crisis | 7-10: Needs attention | 11-13: Good | 14-16: Excellent --- ## Phase 1: Branching Strategy Selection ### Strategy Comparison Matrix | Strategy | Best For | Team Size | Release Cadence | Complexity | |----------|----------|-----------|-----------------|------------| | **GitHub Flow** | SaaS, continuous deploy | 1-15 | Daily/on-demand | Low | | **GitFlow** | Packaged software, versioned releases | 5-50 | Scheduled (2-6 wk) | High | | **Trunk-Based** | High-performing teams, CI/CD mature | 5-100+ | Multiple/day | Low | | **GitLab Flow** | Environment-based deploys | 5-30 | Environment-triggered | Medium | | **Release Flow** | Large monorepos (Microsoft-style) | 50+ | Scheduled + hotfix | Medium | | **Ship/Show/Ask** | High-trust, mixed urgency | 3-20 | Continuous | Low | ### Decision Tree ``` Q1: How often do you deploy to production? ├─ Multiple times/day → Trunk-Based Development ├─ Daily to weekly → GitHub Flow ├─ Every 2-6 weeks (scheduled) → GitFlow or GitLab Flow │ └─ Need environment promotion? → GitLab Flow │ └─ Need parallel release support? → GitFlow └─ Infrequently / packaged software → GitFlow ``` ### Branch Naming Convention ```yaml branch_naming: pattern: "{type}/{ticket}-{short-description}" types: - feat # New feature - fix # Bug fix - hotfix # Production emergency - chore # Maintenance, deps - docs # Documentation - refactor # Code restructure - test # Test additions - perf # Performance examples: - "feat/PROJ-123-user-authentication" - "fix/PROJ-456-login-timeout" - "hotfix/PROJ-789-payment-crash" rules: - lowercase only, hyphens for spaces - max 50 characters after type/ - always include ticket number - delete after merge (automated) ``` ### Branch Lifetime Targets | Branch Type | Target Lifetime | Max Lifetime | Action if Exceeded | |-------------|----------------|--------------|-------------------| | Feature | 1-3 days | 5 days | Split into smaller PRs | | Bugfix | <1 day | 2 days | Prioritize review | | Hotfix | <4 hours | 1 day | Emergency review process | | Release | 1-3 days | 1 week | Only bug fixes, no features | --- ## Phase 2: Commit Engineering ### Conventional Commits Standard ``` ():