Git Engineering & Repository Strategy

Expert guidance on designing branching strategies, commit standards, code review workflows, monorepo management, automated releases, and maintaining scalable...

1kalin@1kalin

Install

openclaw skills install @1kalin/afrexai-git-engineering

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

text

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

text

<type>(<scope>): <subject>

<body>

<footer>

Type Reference:

Type	When	Example
`feat`	New feature	`feat(auth): add SSO login`
`fix`	Bug fix	`fix(api): handle null response`
`perf`	Performance	`perf(db): add index on users.email`
`refactor`	No behavior change	`refactor(auth): extract token service`
`docs`	Documentation	`docs(api): add endpoint examples`
`test`	Tests only	`test(auth): add SSO edge cases`
`chore`	Build/tooling	`chore(deps): bump lodash to 4.17.21`
`ci`	CI/CD changes	`ci: add coverage threshold check`
`style`	Formatting only	`style: apply prettier`
`revert`	Revert previous	`revert: feat(auth): add SSO login`

Breaking Changes:

text

feat(api)!: change auth header format

BREAKING CHANGE: Authorization header now requires "Bearer " prefix.
Migration: Update all API clients to include "Bearer " before token.

Commit Quality Rules

Atomic commits — one logical change per commit
Imperative mood — "add feature" not "added feature"
Subject line ≤72 chars — fits in git log
Body wraps at 72 chars — readable in terminal
Reference issues — Fixes #123 or Refs PROJ-456
No WIP commits on main — squash or interactive rebase first
Sign commits — git config commit.gpgsign true

Interactive Rebase Before Merge

bash

# Clean up feature branch before PR
git rebase -i main

# Common operations:
# pick   → keep commit as-is
# squash → combine with previous
# fixup  → combine, discard message
# reword → change commit message
# drop   → remove commit entirely

# Golden rule: Never rebase shared/public branches

Commit Message Template

yaml

# .gitmessage template
commit_template: |
  # <type>(<scope>): <subject>
  #
  # Why this change?
  #
  # What changed?
  #
  # Refs: PROJ-XXX
  #
  # Types: feat|fix|perf|refactor|docs|test|chore|ci|style|revert
  # Breaking: add ! after type or BREAKING CHANGE: in footer

Phase 3: Code Review & Pull Request Workflow

PR Template

yaml

pr_template:
  title: "{type}({scope}): {description} [PROJ-XXX]"
  body: |
    ## What
    <!-- What does this PR do? One sentence. -->

    ## Why
    <!-- Why is this change needed? Link to issue/RFC. -->

    ## How
    <!-- Technical approach. Key decisions. -->

    ## Testing
    <!-- How was this tested? -->
    - [ ] Unit tests pass
    - [ ] Integration tests pass
    - [ ] Manual testing done
    - [ ] Edge cases covered

    ## Screenshots
    <!-- UI changes only -->

    ## Checklist
    - [ ] Self-reviewed my code
    - [ ] Added/updated tests
    - [ ] Updated documentation
    - [ ] No new warnings
    - [ ] Breaking changes documented
    - [ ] Migration guide included (if breaking)
  labels:
    size:
      xs: "<10 lines"
      s: "10-50 lines"
      m: "50-200 lines"
      l: "200-500 lines"
      xl: ">500 lines — consider splitting"

PR Size Guidelines

Size	Lines Changed	Review Time	Defect Rate
XS	<10	5 min	~0%
S	10-50	15 min	~5%
M	50-200	30 min	~15%
L	200-500	60 min	~25%
XL	>500	120+ min	~40%

Rule: PRs >400 lines have 40% higher defect rate. Split aggressively.

Review SLAs

Priority	First Review	Approval	Escalation
Hotfix	30 min	1 hour	Page on-call
Critical	2 hours	4 hours	Slack team lead
Normal	4 hours	24 hours	Daily standup
Low	24 hours	48 hours	Weekly review

Review Quality Checklist

yaml

review_checklist:
  correctness:
    - Does this solve the stated problem?
    - Are edge cases handled?
    - Could this break existing functionality?
  design:
    - Is the approach appropriate for the problem?
    - Does it follow existing patterns?
    - Is it the simplest solution that works?
  readability:
    - Can I understand this without the PR description?
    - Are names descriptive and consistent?
    - Are complex sections commented?
  testing:
    - Are tests meaningful (not just coverage padding)?
    - Do tests cover the happy path AND edge cases?
    - Are tests maintainable?
  security:
    - No hardcoded secrets or credentials
    - Input validation present
    - No SQL injection / XSS vectors
  performance:
    - No N+1 queries introduced
    - No unnecessary allocations in hot paths
    - Appropriate caching considered

Review Comment Taxonomy

Prefix comments to clarify intent:

Prefix	Meaning	Blocks Merge?
`blocking:`	Must fix before merge	Yes
`suggestion:`	Consider this improvement	No
`nit:`	Style/formatting preference	No
`question:`	Need clarification	Maybe
`praise:`	Great work, learned something	No
`thought:`	Long-term consideration	No

Approval Rules by Change Type

Change Type	Min Approvals	Required Reviewers	Auto-merge?
Feature	2	1 domain expert	No
Bug fix	1	Any team member	Optional
Hotfix	1	On-call + lead	After deploy
Refactor	2	Original author if available	No
Docs only	1	Any	Yes
Dependency update	1	Security-aware reviewer	Dependabot: yes
Config change	2	Ops + dev	No
Database migration	2	DBA/senior + 1 dev	No

Phase 4: Branch Protection & CI Integration

Branch Protection Configuration

yaml

branch_protection:
  main:
    required_reviews: 2
    dismiss_stale_reviews: true
    require_code_owner_reviews: true
    require_signed_commits: true
    require_linear_history: true  # No merge commits
    require_status_checks:
      - "ci/build"
      - "ci/test"
      - "ci/lint"
      - "ci/security-scan"
      - "ci/type-check"
    restrict_push: [release-bot]
    allow_force_push: false
    allow_deletions: false
    require_conversation_resolution: true

  develop:  # If using GitFlow
    required_reviews: 1
    require_status_checks:
      - "ci/build"
      - "ci/test"

  "release/*":
    required_reviews: 2
    restrict_push: [release-managers]
    allow_force_push: false

Pre-merge CI Pipeline

yaml

ci_pipeline:
  stages:
    - name: "Lint & Format"
      parallel: true
      checks:
        - eslint / ruff / clippy
        - prettier / black / gofmt
        - commitlint (conventional commits)
      target: "<30 seconds"

    - name: "Type Check"
      checks:
        - tsc --noEmit --strict
        - mypy / pyright
      target: "<60 seconds"

    - name: "Unit Tests"
      checks:
        - jest / pytest / go test
        - coverage threshold (≥80%)
      target: "<3 minutes"

    - name: "Integration Tests"
      checks:
        - API tests
        - Database migration test
      target: "<5 minutes"

    - name: "Security Scan"
      parallel: true
      checks:
        - dependency audit (npm audit / safety)
        - SAST (semgrep / CodeQL)
        - secrets detection (gitleaks / trufflehog)
      target: "<2 minutes"

    - name: "Build"
      checks:
        - Docker build
        - Bundle size check
      target: "<3 minutes"

  total_target: "<10 minutes"
  rules:
    - All checks must pass before merge
    - Flaky tests quarantined within 24h
    - New code must not decrease coverage
    - Security findings block merge (high/critical)

CODEOWNERS Configuration

text

# .github/CODEOWNERS

# Default
* @team-leads

# Infrastructure
/infra/           @platform-team
/terraform/       @platform-team
/.github/         @platform-team
Dockerfile        @platform-team

# API
/src/api/         @backend-team
/src/middleware/   @backend-team

# Frontend
/src/components/  @frontend-team
/src/pages/       @frontend-team

# Database
/migrations/      @dba-team @backend-team

# Docs
/docs/            @docs-team

# Security-sensitive
/src/auth/        @security-team @backend-team
/src/crypto/      @security-team

Phase 5: Release Management & Versioning

Semantic Versioning (SemVer)

text

MAJOR.MINOR.PATCH[-prerelease][+build]

Examples:
  1.0.0        → First stable release
  1.1.0        → New feature, backward compatible
  1.1.1        → Bug fix
  2.0.0        → Breaking change
  2.0.0-beta.1 → Pre-release
  2.0.0-rc.1   → Release candidate

Version Bump Decision

Change Type	Version Bump	Example
Breaking API change	MAJOR	Remove endpoint, change response shape
New feature (backward compatible)	MINOR	Add endpoint, new optional field
Bug fix	PATCH	Fix calculation error, typo
Performance improvement	PATCH	Optimize query (same behavior)
Dependency update (compatible)	PATCH	Bump lodash minor
Dependency update (breaking)	Depends	Evaluate downstream impact

Automated Release Pipeline

yaml

release_pipeline:
  trigger: merge to main (or release branch)
  steps:
    1_version:
      tool: "semantic-release / release-please / changesets"
      action: "Determine version bump from commits"

    2_changelog:
      action: "Generate CHANGELOG.md from conventional commits"
      sections:
        - "🚀 Features" (feat)
        - "🐛 Bug Fixes" (fix)
        - "⚡ Performance" (perf)
        - "💥 Breaking Changes" (!)
        - "📝 Documentation" (docs)
        - "🔧 Maintenance" (chore)

    3_tag:
      action: "Create signed git tag"
      format: "v{major}.{minor}.{patch}"

    4_release:
      action: "Create GitHub Release with changelog"
      assets:
        - build artifacts
        - checksums

    5_publish:
      action: "Publish to package registry"
      registries:
        - npm / PyPI / Maven / Docker Hub

    6_notify:
      action: "Post to Slack #releases"
      template: "🚀 {package} v{version} released — {changelog_url}"

Release Tool Comparison

Tool	Approach	Monorepo	Config
semantic-release	Fully automated	Via plugins	.releaserc
release-please	PR-based	Native	release-please-config.json
changesets	Developer-driven	Native	.changeset/
standard-version	Local CLI	No	.versionrc
lerna	Monorepo-specific	Yes	lerna.json

Selection Guide:

Want zero-touch automation? → semantic-release
Want human review before release? → release-please
Want developer-controlled changelogs? → changesets
Monorepo with independent packages? → changesets or lerna

Hotfix Process

yaml

hotfix_process:
  trigger: "Production incident requiring code fix"
  steps:
    1: "Create branch from latest release tag: hotfix/PROJ-XXX-description"
    2: "Implement fix with test"
    3: "PR with 'hotfix' label → expedited review (1 reviewer)"
    4: "Merge to main AND release branch (if using GitFlow)"
    5: "Tag patch release immediately"
    6: "Deploy to production"
    7: "Cherry-pick to develop (if using GitFlow)"
    8: "Post-incident: add regression test to CI"
  sla: "Fix deployed within 4 hours of identification"

Phase 6: Monorepo vs Multi-Repo Strategy

Decision Matrix

Factor	Monorepo	Multi-Repo
Code sharing	Trivial (same tree)	Requires packages/versioning
Refactoring	Atomic cross-project changes	Coordinated multi-repo PRs
CI complexity	Higher (affected-only builds)	Simpler (per-repo pipelines)
Dependency management	Single lockfile, consistent	Independent, may drift
Team autonomy	Lower (shared conventions)	Higher (own rules)
Onboarding	One clone, full context	Clone what you need
Build times	Can grow large	Naturally bounded
Access control	Coarser (same repo)	Fine-grained (per-repo)

When to Use Each

Monorepo When:

Shared libraries change frequently
Teams need atomic cross-package changes
Tight integration between services
Strong shared tooling culture
<50 active contributors OR excellent tooling

Multi-Repo When:

Teams are autonomous (different stacks, cadences)
Strong security boundaries needed
Open source components mixed with private
100 contributors without monorepo tooling
Microservices with stable API contracts

Monorepo Tooling

Tool	Language	Features	Best For
Turborepo	JS/TS	Fast, simple, caching	JS/TS monorepos
Nx	Any	Full-featured, generators	Large JS/TS + mixed
Bazel	Any	Hermetic, scalable	Google-scale, polyglot
Pants	Python, Go, Java	Incremental, remote cache	Python-heavy
Rush	JS/TS	Microsoft-backed	Enterprise JS/TS
Lerna	JS/TS	Publishing-focused	npm package sets

Monorepo Structure

text

/
├── apps/
│   ├── web/              # Next.js frontend
│   ├── api/              # Express backend
│   ├── mobile/           # React Native
│   └── admin/            # Admin dashboard
├── packages/
│   ├── ui/               # Shared components
│   ├── utils/            # Shared utilities
│   ├── config/           # Shared configs (eslint, tsconfig)
│   ├── database/         # Prisma/Drizzle schema
│   └── types/            # Shared TypeScript types
├── tools/
│   ├── scripts/          # Build/deploy scripts
│   └── generators/       # Code generators
├── .github/
│   ├── workflows/        # CI/CD
│   └── CODEOWNERS
├── turbo.json            # Turborepo config
├── package.json          # Root workspace
└── pnpm-workspace.yaml   # Workspace definition

Affected-Only CI for Monorepos

yaml

monorepo_ci:
  strategy: "Only build/test what changed"
  detection:
    - "git diff --name-only origin/main...HEAD"
    - "Use tool-native affected detection (nx affected, turbo --filter)"
  caching:
    local: "node_modules/.cache, .turbo"
    remote: "S3/GCS for CI cache sharing"
    key: "hash of lockfile + source files"
  rules:
    - "Root config change → rebuild everything"
    - "Package change → rebuild package + dependents"
    - "App change → rebuild only that app"
    - "Docs change → skip build, only lint"

Phase 7: Git Security

Secrets Prevention

yaml

secrets_prevention:
  pre_commit:
    tool: "gitleaks / trufflehog / detect-secrets"
    config: |
      # .gitleaks.toml
      [allowlist]
      paths = ["test/fixtures/**", "docs/examples/**"]

      [[rules]]
      id = "aws-access-key"
      description = "AWS Access Key"
      regex = '''AKIA[0-9A-Z]{16}'''
      tags = ["aws", "credentials"]

  ci_scan:
    tool: "trufflehog --since-commit HEAD~1"
    action: "Block merge on detection"

  emergency_response:
    steps:
      1: "Revoke the exposed credential IMMEDIATELY"
      2: "git filter-repo to remove from history"
      3: "Force push cleaned history"
      4: "Audit access logs for the exposed credential"
      5: "Rotate all credentials that may have been exposed"
      6: "Add pattern to pre-commit hook"
    warning: |
      Even after removing from history, assume the secret is compromised.
      Anyone who cloned the repo may have it cached.

Commit Signing

bash

# GPG signing setup
git config --global commit.gpgsign true
git config --global user.signingkey YOUR_KEY_ID
git config --global tag.gpgsign true

# SSH signing (GitHub, simpler)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Verify signed commits
git log --show-signature

.gitignore Best Practices

yaml

gitignore_checklist:
  always_ignore:
    - "node_modules/ / venv/ / __pycache__/"
    - ".env / .env.local / .env.*.local"
    - "*.key / *.pem / *.p12"
    - ".DS_Store / Thumbs.db"
    - "*.log / logs/"
    - "dist/ / build/ / out/"
    - "coverage/ / .nyc_output/"
    - ".idea/ / .vscode/ (except shared settings)"
    - "*.sqlite / *.db (unless intentional)"
  never_ignore:
    - ".gitignore itself"
    - "lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml)"
    - ".env.example (template without secrets)"
    - "docker-compose.yml"
    - "Makefile / Taskfile"
  template: "Use github.com/github/gitignore as base"

Phase 8: Git Workflows for Common Scenarios

Feature Development (GitHub Flow)

yaml

feature_workflow:
  steps:
    1_branch: "git checkout -b feat/PROJ-123-description main"
    2_develop:
      - "Make atomic commits following conventional commits"
      - "Push regularly (at least daily)"
      - "Keep rebased on main: git rebase main"
    3_pr:
      - "Open PR early as draft for visibility"
      - "Convert to ready when tests pass"
      - "Request reviewers via CODEOWNERS"
    4_review:
      - "Address feedback in new commits (don't force-push during review)"
      - "Re-request review after changes"
    5_merge:
      - "Squash merge for clean history"
      - "Delete branch after merge (automated)"
    6_deploy:
      - "CI/CD deploys from main automatically"

Trunk-Based Development

yaml

trunk_based:
  rules:
    - "All developers commit to main (or short-lived branches <1 day)"
    - "Feature flags gate incomplete features"
    - "No long-lived branches (ever)"
    - "Broken main = stop everything, fix immediately"
    - "Pair programming reduces need for PR reviews"
  short_lived_branches:
    max_lifetime: "1 day"
    merge_strategy: "squash"
    review: "Optional for small changes, required for >50 LOC"
  prerequisites:
    - "Comprehensive CI pipeline (<10 min)"
    - "Feature flag infrastructure"
    - "High test coverage (>80%)"
    - "Trunk-based CI (main always deployable)"
    - "Strong automated testing culture"

Database Migration Workflow

yaml

migration_workflow:
  rules:
    - "One migration per PR (never batch)"
    - "Migrations are forward-only (no down migrations in production)"
    - "Every migration must be backward compatible"
    - "Test migration against production data clone"
  backward_compatible_patterns:
    add_column: "Add with default value, make nullable initially"
    rename_column: "Add new → migrate data → update code → drop old (3 PRs)"
    remove_column: "Stop reading → stop writing → drop (2 PRs)"
    add_index: "CREATE INDEX CONCURRENTLY"
    change_type: "Add new column → migrate → swap → drop old"
  review:
    required_reviewers: ["dba", "senior-backend"]
    extra_checks:
      - "Migration runs in <30 seconds"
      - "No table locks on large tables"
      - "Rollback tested"

Dependency Update Workflow

yaml

dependency_updates:
  automation:
    tool: "Dependabot / Renovate"
    config:
      schedule: "weekly"
      group_by: "update-type"
      automerge:
        - "patch updates (tests pass)"
        - "minor updates (for low-risk deps)"
      manual_review:
        - "major updates"
        - "security-sensitive packages"

  renovate_config:
    # renovate.json
    extends: ["config:recommended"]
    schedule: ["before 9am on Monday"]
    automerge: true
    automergeType: "pr"
    packageRules:
      - matchUpdateTypes: ["patch"]
        automerge: true
      - matchUpdateTypes: ["major"]
        automerge: false
        reviewers: ["team/leads"]
      - matchPackagePatterns: ["eslint", "prettier", "typescript"]
        groupName: "dev tooling"

Phase 9: Git Performance & Large Repos

Performance Optimization

Problem	Solution	Impact
Slow clone	`git clone --depth 1` (shallow)	10-100x faster
Large repo	`git sparse-checkout`	Clone only needed dirs
Slow fetch	`git fetch --prune --tags`	Remove stale refs
Large files	Git LFS	Keep repo size manageable
Slow status	`git config core.fsmonitor true`	2-5x faster on large repos
Slow diff	`git config diff.algorithm histogram`	Better diff quality
Many branches	Auto-delete merged branches	Keep ref count low

Git LFS Setup

yaml

git_lfs:
  when_to_use:
    - "Binary files >1MB (images, videos, models)"
    - "Generated files that change frequently"
    - "Design assets (PSD, Sketch, Figma exports)"
  never_lfs:
    - "Source code"
    - "Configuration files"
    - "Small images (<100KB)"
  setup: |
    git lfs install
    git lfs track "*.psd"
    git lfs track "*.zip"
    git lfs track "models/**"
    git add .gitattributes
  cost_warning: |
    GitHub LFS: 1GB free, then $5/50GB/month
    Consider alternatives for very large assets:
    - S3/GCS with download scripts
    - DVC (Data Version Control) for ML
    - Git Annex for large media

Sparse Checkout for Monorepos

bash

# Clone only what you need
git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout init --cone
git sparse-checkout set apps/my-app packages/shared

# Add more directories later
git sparse-checkout add packages/another-lib

Phase 10: Git Troubleshooting & Recovery

Common Issues & Fixes

Problem	Command	Notes
Undo last commit (keep changes)	`git reset --soft HEAD~1`	Staged, ready to recommit
Undo last commit (discard)	`git reset --hard HEAD~1`	⚠️ Destructive
Find lost commit	`git reflog`	Reflog keeps 90 days
Recover deleted branch	`git reflog` → `git checkout -b branch <sha>`	Find the SHA in reflog
Remove file from all history	`git filter-repo --path file --invert-paths`	Requires force push
Fix wrong branch	`git stash` → `git checkout correct` → `git stash pop`
Resolve merge conflict	`git mergetool` or manual edit	Accept theirs: `git checkout --theirs file`
Bisect to find bug	`git bisect start` → `git bisect bad` → `git bisect good <sha>`	Binary search
Squash last N commits	`git rebase -i HEAD~N`	Mark as squash/fixup
Amend last commit message	`git commit --amend`	Only if not pushed

Emergency Procedures

yaml

emergency_procedures:
  secrets_in_repo:
    severity: "CRITICAL"
    steps:
      1: "Revoke credential IMMEDIATELY (don't wait for history clean)"
      2: "Remove with git filter-repo"
      3: "Force push all branches"
      4: "Contact GitHub support to clear caches"
      5: "Audit credential usage"
      6: "Add to pre-commit hooks"

  broken_main:
    severity: "HIGH"
    steps:
      1: "Revert the breaking commit: git revert <sha>"
      2: "Push revert immediately"
      3: "Investigate in separate branch"
      4: "Fix forward (don't revert the revert)"

  accidental_force_push:
    severity: "HIGH"
    steps:
      1: "Check reflog for the previous HEAD"
      2: "Reset to previous state"
      3: "Force push the recovery"
      4: "Notify team to re-pull"
      5: "Add branch protection to prevent recurrence"

  repo_too_large:
    severity: "MEDIUM"
    steps:
      1: "Identify large files: git rev-list --objects --all | git cat-file --batch-check"
      2: "Move large files to LFS: git lfs migrate import --include='*.zip'"
      3: "Or remove with filter-repo"
      4: "Force push cleaned history"
      5: "Team re-clones"

Phase 11: Advanced Patterns

Git Hooks Architecture

yaml

git_hooks:
  tool: "husky (JS) / pre-commit (Python) / lefthook (any)"
  recommended_hooks:
    pre_commit:
      - lint-staged (format only changed files)
      - commitlint (conventional commit check)
      - gitleaks (secrets scan)
    commit_msg:
      - commitlint --edit $1
    pre_push:
      - type-check
      - unit tests (fast subset)
    prepare_commit_msg:
      - Add branch ticket number to commit

  lefthook_config: |
    # lefthook.yml
    pre-commit:
      parallel: true
      commands:
        lint:
          glob: "*.{ts,tsx,js,jsx}"
          run: npx eslint {staged_files}
        format:
          glob: "*.{ts,tsx,js,jsx,json,md}"
          run: npx prettier --check {staged_files}
        secrets:
          run: gitleaks protect --staged

    commit-msg:
      commands:
        lint-commit:
          run: npx commitlint --edit {1}

Worktrees for Parallel Development

bash

# Work on hotfix while feature branch is open
git worktree add ../hotfix-workspace hotfix/PROJ-789
cd ../hotfix-workspace
# Fix, commit, push — without touching main workspace
git worktree remove ../hotfix-workspace

# Use cases:
# - Reviewing PR while working on feature
# - Running tests on one branch while coding on another
# - Comparing behavior between branches

Git Subtree for Shared Libraries

bash

# Add shared library
git subtree add --prefix=libs/shared https://github.com/org/shared.git main --squash

# Pull updates
git subtree pull --prefix=libs/shared https://github.com/org/shared.git main --squash

# Push changes back
git subtree push --prefix=libs/shared https://github.com/org/shared.git feature-branch

# When to use subtree vs submodule:
# Subtree: simpler, code lives in your repo, no extra clone steps
# Submodule: pointer to external repo, separate versioning, requires init

Changelog Generation

yaml

changelog_tools:
  conventional_changelog:
    command: "npx conventional-changelog -p angular -i CHANGELOG.md -s"
    output: "Groups by feat/fix/perf with commit links"

  git_cliff:
    command: "git cliff --output CHANGELOG.md"
    config: |
      # cliff.toml
      [changelog]
      header = "# Changelog\n"
      body = """
      ## [{{ version }}] - {{ timestamp | date(format="%Y-%m-%d") }}
      {% for group, commits in commits | group_by(attribute="group") %}
      ### {{ group }}
      {% for commit in commits %}
      - {{ commit.message }} ([{{ commit.id | truncate(length=7) }}]({{ commit.id }}))
      {% endfor %}
      {% endfor %}
      """
      trim = true

  release_please:
    approach: "Creates PR with changelog + version bump"
    config: |
      {
        "release-type": "node",
        "packages": { ".": {} }
      }

Phase 12: Metrics & Health Dashboard

Weekly Repository Health Dashboard

yaml

repo_health_dashboard:
  date: "YYYY-MM-DD"
  
  velocity:
    prs_merged_this_week: 0
    avg_pr_size_lines: 0
    avg_time_to_first_review_hours: 0
    avg_time_to_merge_hours: 0
    
  quality:
    prs_requiring_rework: 0
    review_comments_per_pr: 0
    ci_pass_rate_percent: 0
    reverts_this_week: 0
    
  hygiene:
    stale_branches_count: 0
    open_prs_older_than_7_days: 0
    unsigned_commits_percent: 0
    ci_pipeline_duration_p95_minutes: 0
    
  security:
    secrets_detected_blocked: 0
    dependency_vulnerabilities_open: 0
    
  scoring:
    dimensions:
      velocity: { weight: 20, score: 0 }
      quality: { weight: 25, score: 0 }
      hygiene: { weight: 20, score: 0 }
      security: { weight: 20, score: 0 }
      culture: { weight: 15, score: 0 }
    total: "/100"

Benchmarks

Metric	Good	Great	World-Class
PR review time	<24h	<4h	<2h
PR merge time	<48h	<24h	<8h
CI pipeline	<15 min	<10 min	<5 min
CI pass rate	>90%	>95%	>99%
Branch lifetime	<5 days	<3 days	<1 day
Stale branches	<20	<10	0
Code review coverage	>80%	>95%	100%
Signed commits	>50%	>90%	100%

100-Point Quality Rubric

Dimension	Weight	0-25	50	75	100
Branching Strategy	15%	No strategy	Basic (main + feature)	Documented, enforced	Automated, measured
Commit Quality	10%	Random messages	Mostly conventional	Enforced conventional + signing	Automated changelog from commits
Code Review	20%	Optional/rubber stamp	Required, basic	SLAs, taxonomy, CODEOWNERS	Data-driven, continuous improvement
CI/CD Integration	15%	Manual checks	Basic pipeline	Branch protection + all checks	<10 min, affected-only, cached
Release Management	10%	Manual	SemVer, manual tagging	Automated versioning	Full automation + changelog + notify
Security	15%	No controls	.gitignore, basic	Pre-commit secrets scan + signing	Full security pipeline + audit
Repository Hygiene	10%	Stale branches, large repo	Periodic cleanup	Automated cleanup, LFS	Monitored dashboard, zero debt
Documentation	5%	None	README + PR template	Contributing guide + ADRs	Full developer onboarding docs

Score: 0-40 = Crisis | 41-60 = Developing | 61-80 = Good | 81-100 = Excellent

10 Git Engineering Mistakes

#	Mistake	Fix
1	Committing secrets	Pre-commit hooks (gitleaks) + CI scan
2	Long-lived branches	Max 5-day policy, split large features
3	Merge commits everywhere	Squash merge or rebase, linear history
4	No branch protection	Enforce reviews + status checks
5	Giant PRs (>500 lines)	Split by concern, stacked PRs
6	Force pushing shared branches	Never force push main/develop
7	No CI before merge	Block merge without passing checks
8	Manual releases	Automate with semantic-release/release-please
9	Ignoring git history	Conventional commits, meaningful messages
10	No CODEOWNERS	Define ownership for review routing

Edge Cases

Startup / Solo Developer

Start with GitHub Flow (simplest)
Use conventional commits from day 1
Set up pre-commit hooks immediately
Branch protection even on solo repos (prevents accidents)

Large Enterprise (>100 devs)

Trunk-Based Development with feature flags
Monorepo with Bazel/Nx + remote caching
CODEOWNERS for every directory
Automated everything (lint, test, release, changelog)

Open Source Project

Require signed commits from maintainers
Fork-based workflow for external contributors
DCO (Developer Certificate of Origin) or CLA
Protected main + develop branches
Issue templates + PR templates mandatory

Migration from SVN/Perforce

Use git svn or git p4 for initial migration
Preserve history where possible
Retrain team on branching (it's cheap in git!)
Start with GitHub Flow, graduate to trunk-based

Regulated Industry (SOX/HIPAA/PCI)

Signed commits mandatory
PR approval from compliance-aware reviewer
Audit trail: never squash (keep individual commits)
Branch protection: no admin override
Tag every production release

Natural Language Commands

Command	Action
"Set up git for our project"	Assess team, recommend branching strategy + full config
"Review our branching strategy"	Analyze current approach, suggest improvements
"Create PR template"	Generate PR template with checklist
"Set up branch protection"	Generate protection rules config
"Help with monorepo setup"	Tool selection + structure + CI config
"Fix git problem"	Diagnose from troubleshooting guide
"Set up automated releases"	Tool selection + pipeline config
"Audit repository security"	Run through security checklist
"Optimize CI pipeline"	Analyze and recommend speedups
"Set up commit conventions"	Configure commitlint + hooks + template
"Create CODEOWNERS"	Generate ownership file from project structure
"Help with git recovery"	Guide through emergency procedures

Git Engineering & Repository Strategy

Install

Git Engineering & Repository Strategy

Quick Health Check (Run First)

Phase 1: Branching Strategy Selection

Strategy Comparison Matrix

Decision Tree

Branch Naming Convention

Branch Lifetime Targets

Phase 2: Commit Engineering

Conventional Commits Standard

Commit Quality Rules

Interactive Rebase Before Merge

Commit Message Template

Phase 3: Code Review & Pull Request Workflow

PR Template

PR Size Guidelines

Review SLAs

Review Quality Checklist

Review Comment Taxonomy

Approval Rules by Change Type

Phase 4: Branch Protection & CI Integration

Branch Protection Configuration

Pre-merge CI Pipeline

CODEOWNERS Configuration

Phase 5: Release Management & Versioning

Semantic Versioning (SemVer)

Version Bump Decision

Automated Release Pipeline

Release Tool Comparison

Hotfix Process

Phase 6: Monorepo vs Multi-Repo Strategy

Decision Matrix

When to Use Each

Monorepo Tooling

Monorepo Structure

Affected-Only CI for Monorepos

Phase 7: Git Security

Secrets Prevention

Commit Signing

.gitignore Best Practices

Phase 8: Git Workflows for Common Scenarios

Feature Development (GitHub Flow)

Trunk-Based Development

Database Migration Workflow

Dependency Update Workflow

Phase 9: Git Performance & Large Repos

Performance Optimization

Git LFS Setup

Sparse Checkout for Monorepos

Phase 10: Git Troubleshooting & Recovery

Common Issues & Fixes

Emergency Procedures

Phase 11: Advanced Patterns

Git Hooks Architecture

Worktrees for Parallel Development

Git Subtree for Shared Libraries

Changelog Generation

Phase 12: Metrics & Health Dashboard

Weekly Repository Health Dashboard

Benchmarks

100-Point Quality Rubric

10 Git Engineering Mistakes

Edge Cases

Startup / Solo Developer

Large Enterprise (>100 devs)

Open Source Project

Migration from SVN/Perforce

Regulated Industry (SOX/HIPAA/PCI)

Natural Language Commands

Related skills