Git Workflow (Modern Team Collaboration)
Use modern Git collaboration patterns: GitHub Flow for continuous deploy, trunk-based for scale, Conventional Commits for automation, stacked diffs for large features.
Use this skill to choose a branching model, standardize PR discipline, enforce commit conventions, and harden repository settings for safe collaboration.
Quick Start
- Identify constraints (team size, release cadence, CI maturity, compliance).
- Choose a branching strategy using the decision tree.
- Apply the baseline repo settings (branch protection, approvals, checks, merge strategy).
- Use the relevant reference doc for implementation details.
- If asked "best practice in 2026", verify via web search using
data/sources.json as a starting source list.
Quick Reference
| Task |
Tool/Command |
When to Use |
Reference |
| Create feature branch |
git switch -c feat/name main |
Start new work |
Branching Strategies |
| Create feature worktree |
git worktree add .worktrees/feature -b feature/name |
Isolate one feature per agent/branch |
AI Agent Worktrees |
| Squash WIP commits |
git rebase -i HEAD~3 |
Clean up before PR |
Interactive Rebase |
| Conventional commit |
git commit -m "feat: add feature" |
All commits |
Commit Conventions |
| Force push safely |
git push --force-with-lease |
After rebase |
Common Mistakes |
| Resolve conflicts |
git mergetool |
Merge conflicts |
Conflict Resolution |
| Create stacked PRs |
gt create stack-name (Graphite) |
Large features |
Stacked Diffs |
| Auto-generate changelog |
npx standard-version |
Before release |
Release Management |
| Run quality gates |
GitHub Actions / GitLab CI |
Every PR |
Automated Quality Gates |
AI Agent Feature Loop
AI Agent Worktrees Reference — Full guide to worktree isolation for Claude Code, Codex, Aider, and other AI coding agents.
flowchart LR
A[Plan] --> B[Create worktree<br>per agent/feature]
B --> C[Verify .gitignore<br>+ install deps]
C --> D[Agent works<br>scoped commits]
D --> E[Quality gates]
E -->|pass| F[PR + merge]
E -->|fail| D
F --> G[Cleanup worktree<br>+ delete branch]
style D fill:#fff3cd,stroke:#d4a017
style F fill:#d4edda,stroke:#28a745
For AI-assisted engineering, prefer this default loop:
- Create one worktree per feature branch (
git worktree add .worktrees/<feature> -b feature/<name>).
- Verify the worktree directory is in
.gitignore (git check-ignore -q .worktrees).
- Install dependencies and verify clean test baseline before starting work.
- Implement scoped changes only for that feature.
- Run repository quality gate(s) before PR.
- Open one focused PR to the integration branch.
- After merge, clean up:
git worktree remove + git branch -d.
Parallel agents: One worktree per agent, disjoint file ownership, orchestrator merges from main. See AI Agent Worktrees for setup, safety patterns, and cleanup.
If repository scripts exist (for example scripts/git/feature-workflow.sh), use them to enforce this loop.
Local Safety Preflight (Before Checkout/Merge/Commit)
Use this quick sequence to avoid common local Git blockers during agent-driven work.
- Working tree cleanliness:
git status --porcelain
- If non-empty, decide explicitly: commit, stash, or abort branch switch.
- Lock/process check:
- If Git commands fail with
index.lock, check running Git processes first:
test -f .git/index.lock && ps aux | rg "[g]it"
- Remove stale lock only after confirming no active Git process.
- Branch switch guard:
- Do not
checkout/switch when local changes would be overwritten.
- Commit/stash intentionally; avoid accidental context loss.
- Merge conflict protocol:
- On conflict, stop new edits, resolve conflict file-by-file, rerun relevant tests, then complete merge commit.
- Automation note:
- For recurring branch operations, prefer project scripts/worktrees over ad-hoc local branch juggling.
Decision Tree: Choosing Branching Strategy
Use this decision tree to select the optimal branching strategy for your team based on team size, release cadence, and CI/CD maturity.
Team characteristics -> What's your situation?
├─ Small team (1-5 devs) + Continuous deployment + High CI/CD maturity?
│ └─ GitHub Flow (main + feature branches)
│
├─ Medium team (5-15 devs) + Continuous deployment + High CI/CD maturity?
│ └─ Trunk-Based Development (main + short-lived branches)
│
├─ Large team (15+ devs) + Continuous deployment + Very high CI/CD maturity?
│ └─ Trunk-Based + Feature Flags (progressive rollout)
│
├─ Scheduled releases + Medium CI/CD maturity?
│ └─ GitFlow (main + develop + release branches)
│
└─ Multiple versions + Low-Medium CI/CD maturity?
└─ GitFlow (long-lived release branches)
Navigation: Core Workflows
Branching Strategies
Branching Strategies Comparison - Comprehensive guide to choosing and implementing branching strategies
- GitHub Flow (recommended for modern teams): Simple, continuous deployment
- Trunk-Based Development (enterprise scale): Short-lived branches, daily merges
- GitFlow (structured releases): Scheduled releases, multiple versions
- Decision matrix: Team size, release cadence, CI/CD maturity
- Migration paths between strategies
Pull Request Best Practices
PR Best Practices Guide - Effective code reviews and fast PR cycles
- PR size guidelines: keep PRs reviewable (often 200-400 LOC works well; split larger changes)
- Review categories: BLOCKER, WARNING, NITPICK
- Review etiquette: Collaborative feedback, code examples
- PR description templates: What, Why, How, Testing
- Data-driven insights on review efficiency
Commit Conventions
Conventional Commits Standard - Commit message formats and semantic versioning integration
- Conventional commit format:
type(scope): description
- Commit types: feat, fix, BREAKING CHANGE, refactor, docs
- SemVer automation: Auto-bump versions from commits
- Changelog generation: Automated from commit history
- Tools: commitlint, semantic-release, standard-version
Navigation: Advanced Techniques
Stacked Diffs
Stacked Diffs Implementation - Platform-specific workflows and team adoption
- What are stacked diffs: Break large features into reviewable chunks
- When to use: Features > 500 lines, complex refactoring
- GitLab native support: MR chains
- GitHub with Graphite: CLI-based stacking
- Benefits: 60% faster review cycles, better quality
Interactive Rebase
Interactive Rebase & History Cleanup - Maintain clean commit history
- Auto-squash workflow:
fixup! and squash! commits
- Interactive rebase commands: pick, reword, edit, squash, fixup, drop
- Splitting commits: Break large commits into focused changes
- Reordering commits: Logical commit history
- Best practices: Never rebase public branches
Conflict Resolution
Conflict Resolution Techniques - Merge strategies and conflict handling
- Resolution strategies:
--ours, --theirs, manual merge
- Rebase vs merge: When to use each
- Merge tool setup: VS Code, Meld, custom tools
- Conflict markers: Understanding
<<<<<<<, =======, >>>>>>>
- Prevention strategies: Frequent rebasing, small PRs
Navigation: Automation & Quality
Automated Quality Gates
Automated Quality Gates - CI/CD pipelines and quality enforcement
- Essential gates: Tests, coverage, linting, security scans
- Advanced gates: Performance benchmarks, bundle size, a11y checks
- GitHub Actions workflows: Complete PR checks pipeline
- GitLab CI pipelines: MR quality gates
- Pre-commit hooks: Husky + lint-staged setup
- Quality metrics thresholds: Coverage 80%, complexity < 10
Validation Checklists
Validation Checklists - Pre-PR, pre-merge, pre-release checklists
- Before creating PR: Code quality, commit hygiene, testing
- Before merging PR: Review process, CI/CD checks, final verification
- Before releasing: Pre-release testing, version management, documentation
- Post-deployment: Immediate verification, monitoring, tasks
- Hotfix checklist: Critical bug fast-track process
Release Management
Release Management - Versioning and deployment workflows
- Semantic versioning: MAJOR.MINOR.PATCH
- Manual release workflow: GitFlow release branches
- Automated releases: semantic-release automation
- Hotfix workflow: Emergency patches
- Changelog generation: Keep a Changelog format
- Release checklists: Pre-release, release day, post-release
Navigation: AI Agent Workflows
AI Agent Worktrees
AI Agent Worktrees - Worktree isolation patterns for AI coding agents
- When to use worktrees with agents (decision table)
- Directory conventions (
.worktrees/, global paths, .gitignore)
- Agent-specific patterns: Claude Code, Codex, Aider, Copilot Workspace
- Parallel agent execution: one worktree per agent, disjoint file ownership
- Safety: lock contention, conflict detection, cross-agent file guards
- Cleanup lifecycle: removal, pruning, batch cleanup scripts
Navigation: Learning & Troubleshooting
Monorepo Workflows
Monorepo Workflows - Git patterns for monorepo repositories
- Trunk-based branching for monorepos
- Sparse checkout and partial clone
- Affected-only CI (Nx, Turborepo, Bazel)
- CODEOWNERS per package/directory
- Monorepo vs polyrepo decision table
Git Hooks Automation
Git Hooks Automation - Pre-commit, commit-msg, pre-push hooks
- Husky v9+ and lefthook setup
- lint-staged and commitlint integration
- Custom hooks (gitleaks, file size limits, branch naming)
- Team distribution strategies
Git Bisect Debugging
Git Bisect Debugging - Regression hunting with git bisect
- Manual and automated bisect workflows
- Writing bisect test scripts
- Handling merge commits, log and replay
Common Mistakes
Common Mistakes & Fixes - Learn from common pitfalls
- Large unfocused PRs -> Split into stacked diffs
- Vague commit messages -> Use conventional commits
- Rewriting public history -> Never rebase main
- Ignoring review comments -> Address all feedback
- Committing secrets -> Use environment variables
- Force push dangers -> Use
--force-with-lease
Decision Tables
When to Use Each Branching Strategy
| Requirement |
GitHub Flow |
Trunk-Based |
GitFlow |
| Continuous deployment |
[OK] Best |
[OK] Best |
[FAIL] Poor |
| Scheduled releases |
[WARNING] OK |
[WARNING] OK |
[OK] Best |
| Multiple versions |
[FAIL] Poor |
[FAIL] Poor |
[OK] Best |
| Small team (< 5) |
[OK] Best |
[WARNING] OK |
[FAIL] Overkill |
| Large team (> 15) |
[WARNING] OK |
[OK] Best |
[WARNING] OK |
| Fast iteration |
[OK] Best |
[OK] Best |
[FAIL] Poor |
PR Size vs Review Time
| LOC |
Review Time |
Bug Detection |
Recommendation |
| < 50 |
< 10 min |
High |
[OK] Ideal for hotfixes |
| 50-200 |
10-30 min |
High |
[OK] Ideal for features |
| 200-400 |
30-60 min |
Medium-High |
[OK] Acceptable |
| 400-1000 |
1-2 hours |
Medium |
[WARNING] Consider splitting |
| > 1000 |
> 2 hours |
Low |
[FAIL] Always split |
Do / Avoid
GOOD: Do
- Keep PRs under 400 lines (200-400 optimal)
- Use conventional commit messages
- Rebase before opening PR (clean history)
- Require at least one approval before merge
- Run CI checks on every PR
- Use stacked diffs for large features (>500 LOC)
- Squash WIP commits before merge
- Use
--force-with-lease (not --force)
BAD: Avoid
- Long-lived feature branches (>3 days)
- Merging without review
- Rebasing public/shared branches
- Force pushing to main/master
- Committing secrets (even "temporarily")
- Large monolithic PRs (>1000 lines)
- Vague commit messages ("fix", "update")
- Skipping CI to merge faster
Anti-Patterns
| Anti-Pattern |
Problem |
Fix |
| Long-lived branches |
Merge conflicts, stale code |
Trunk-based, short branches |
| Unreviewed merges |
Bugs reach production |
Branch protection rules |
| Rebasing main |
History corruption |
Never rebase public branches |
| 1000+ LOC PRs |
Poor review quality |
Stacked diffs, split PRs |
| "fix" commits |
Unclear history |
Conventional commits |
| No CI gates |
Broken main |
Required status checks |
| Secrets in history |
Security breach |
Pre-commit hooks, gitleaks |
Repository Baseline (Security + Reliability)
Set these repo defaults before scaling a team:
- Branch protection: require PRs to
main (no direct pushes), require status checks, require up-to-date branch on merge.
- Review gates: require approvals; enforce CODEOWNERS for sensitive paths (auth, payments, infra, prod configs).
- History policy: pick merge strategy (squash vs merge commits) and make it consistent; document exceptions.
- Signed changes: require signed commits and signed tags for releases (team-specific key management).
- Secret prevention: local pre-commit + server-side secret scanning/push protection; rotate on incident.
- Merge safety: use merge queue (or equivalent) for busy repos to keep
main green under high concurrency.
- Cost control: cache dependencies/builds; run heavy jobs conditionally; cap CI minutes for untrusted forks.
Template: assets/pull-requests/pr-template.md
Guide: assets/template-git-workflow-guide.md
Security-Sensitive Changes
For security-related git operations, see dev-git-commit-message/assets/template-security-commits.md:
- Secrets detection with pre-commit hooks
- Handling accidental secret commits
- Security commit metadata (CVE, CVSS)
- Branch protection for security-sensitive code
Optional: AI/Automation
Note: AI tools assist but cannot replace human judgment for merge decisions.
- PR summarization - Generate description from commits
- Change risk labeling - Flag high-risk files (auth, payments)
- Review suggestions - Identify potential reviewers
Bounded Claims
- AI summaries need human verification
- Risk labels are suggestions, not guarantees
- Merge decisions always require human approval
Related Skills
Usage Notes
For Claude Code:
- Recommend GitHub Flow for most modern teams (simple, effective)
- Suggest stacked diffs for features > 500 lines
- Always validate commit messages against conventional commit format
- Check PR size - warn if > 400 lines, block if > 1000 lines
- Reference assets/ for copy-paste ready configurations
- Use references/ for deep-dive implementation guidance
Progressive Disclosure:
- Start with Quick Reference for fast lookups
- Use Decision Tree for choosing strategies
- Navigate to specific resources for detailed implementation
- Reference templates for production-ready configurations
- Check validation checklists before PR/merge/release
Quick Command Reference
Common Operations:
# Rebase feature branch
git fetch origin && git rebase origin/main
# Interactive rebase last 3 commits
git rebase -i HEAD~3
# Squash all commits in branch
git rebase -i $(git merge-base HEAD main)
# Force push safely
git push --force-with-lease origin feature-branch
# Undo last commit (keep changes)
git reset --soft HEAD~1
# Cherry-pick specific commit
git cherry-pick abc123
# Stash changes
git stash push -m "WIP: implementing feature X"
git stash pop
Conflict Resolution:
# Pull latest with rebase
git pull --rebase origin main
# Use visual merge tool
git mergetool
# Accept their changes
git checkout --theirs <file>
# Accept your changes
git checkout --ours <file>
Trend Awareness Protocol
IMPORTANT: When users ask recommendation questions about Git workflows, branching strategies, or collaboration tools, verify current trends via web search (and/or the links in data/sources.json) before answering.
Trigger Conditions
- "What's the best Git workflow for [team size/use case]?"
- "What should I use for [branching/PR management]?"
- "What's the latest in Git collaboration?"
- "Current best practices for [branching/code review]?"
- "Is [GitFlow/Trunk-Based] still relevant in 2026?"
- "[GitHub Flow] vs [Trunk-Based] vs [GitFlow]?"
- "Best PR stacking tool?"
Required Searches
- Search:
"Git workflow best practices 2026"
- Search:
"[specific strategy] vs alternatives 2026"
- Search:
"Git collaboration trends January 2026"
- Search:
"[branching/PR tools] comparison 2026"
What to Report
After searching, provide:
- Current landscape: What Git workflows/tools are popular NOW
- Emerging trends: New collaboration patterns, tools, or practices gaining traction
- Deprecated/declining: Strategies/tools losing relevance or support
- Recommendation: Based on fresh data, not just static knowledge
Example Topics (verify with fresh search)
- Branching strategies (Trunk-Based, GitHub Flow, GitFlow)
- PR stacking tools (Graphite, git-stack, Stacked PRs)
- Merge queue implementations (GitHub, GitLab)
- Code review platforms and automation
- Conventional commits and changelog tools
- Git hosting platform features (GitHub, GitLab, Bitbucket)
- AI-assisted Git workflows
Fact-Checking
- Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
- Prefer primary sources; report source links and dates for volatile information.
- If web access is unavailable, state the limitation and mark guidance as unverified.
1---2name: dev-git-workflow3description: Team Git patterns for branching, PRs, commits, and code review. Use when choosing a branching model or hardening repo collaboration.4---5
6# Git Workflow (Modern Team Collaboration)
7
8Use modern Git collaboration patterns: GitHub Flow for continuous deploy, trunk-based for scale, Conventional Commits for automation, stacked diffs for large features.
9
10Use this skill to choose a branching model, standardize PR discipline, enforce commit conventions, and harden repository settings for safe collaboration.
11
12## Quick Start
13
141. Identify constraints (team size, release cadence, CI maturity, compliance).
152. Choose a branching strategy using the decision tree.
163. Apply the baseline repo settings (branch protection, approvals, checks, merge strategy).
174. Use the relevant reference doc for implementation details.
185. If asked "best practice in 2026", verify via web search using `data/sources.json` as a starting source list.
19
20## Quick Reference
21
22| Task | Tool/Command | When to Use | Reference |
23|------|-------------|-------------|-----------|
24| Create feature branch | `git switch -c feat/name main` | Start new work | [Branching Strategies](references/branching-strategies.md) |
25| Create feature worktree | `git worktree add .worktrees/feature -b feature/name` | Isolate one feature per agent/branch | [AI Agent Worktrees](references/ai-agent-worktrees.md) |
26| Squash WIP commits | `git rebase -i HEAD~3` | Clean up before PR | [Interactive Rebase](references/interactive-rebase-guide.md) |
27| Conventional commit | `git commit -m "feat: add feature"` | All commits | [Commit Conventions](references/commit-conventions.md) |
28| Force push safely | `git push --force-with-lease` | After rebase | [Common Mistakes](references/common-mistakes.md) |
29| Resolve conflicts | `git mergetool` | Merge conflicts | [Conflict Resolution](references/conflict-resolution.md) |
30| Create stacked PRs | `gt create stack-name` (Graphite) | Large features | [Stacked Diffs](references/stacked-diffs-guide.md) |
31| Auto-generate changelog | `npx standard-version` | Before release | [Release Management](references/release-management.md) |
32| Run quality gates | GitHub Actions / GitLab CI | Every PR | [Automated Quality Gates](references/automated-quality-gates.md) |
33
34
35## AI Agent Feature Loop
36
37**[AI Agent Worktrees Reference](references/ai-agent-worktrees.md)** — Full guide to worktree isolation for Claude Code, Codex, Aider, and other AI coding agents.
38
39```mermaid
40flowchart LR
41 A[Plan] --> B[Create worktree<br>per agent/feature]
42 B --> C[Verify .gitignore<br>+ install deps]
43 C --> D[Agent works<br>scoped commits]
44 D --> E[Quality gates]
45 E -->|pass| F[PR + merge]
46 E -->|fail| D
47 F --> G[Cleanup worktree<br>+ delete branch]
48
49 style D fill:#fff3cd,stroke:#d4a017
50 style F fill:#d4edda,stroke:#28a745
51```
52
53For AI-assisted engineering, prefer this default loop:
54
551. Create one worktree per feature branch (`git worktree add .worktrees/<feature> -b feature/<name>`).
562. Verify the worktree directory is in `.gitignore` (`git check-ignore -q .worktrees`).
573. Install dependencies and verify clean test baseline before starting work.
584. Implement scoped changes only for that feature.
595. Run repository quality gate(s) before PR.
606. Open one focused PR to the integration branch.
617. After merge, clean up: `git worktree remove` + `git branch -d`.
62
63**Parallel agents:** One worktree per agent, disjoint file ownership, orchestrator merges from main. See [AI Agent Worktrees](references/ai-agent-worktrees.md) for setup, safety patterns, and cleanup.
64
65If repository scripts exist (for example `scripts/git/feature-workflow.sh`), use them to enforce this loop.
66
67## Local Safety Preflight (Before Checkout/Merge/Commit)
68
69Use this quick sequence to avoid common local Git blockers during agent-driven work.
70
711. Working tree cleanliness:
72- `git status --porcelain`
73- If non-empty, decide explicitly: commit, stash, or abort branch switch.
74
752. Lock/process check:
76- If Git commands fail with `index.lock`, check running Git processes first:
77 - `test -f .git/index.lock && ps aux | rg "[g]it"`
78- Remove stale lock only after confirming no active Git process.
79
803. Branch switch guard:
81- Do not `checkout`/`switch` when local changes would be overwritten.
82- Commit/stash intentionally; avoid accidental context loss.
83
844. Merge conflict protocol:
85- On conflict, stop new edits, resolve conflict file-by-file, rerun relevant tests, then complete merge commit.
86
875. Automation note:
88- For recurring branch operations, prefer project scripts/worktrees over ad-hoc local branch juggling.
89
90
91## Decision Tree: Choosing Branching Strategy
92
93```text
94Use this decision tree to select the optimal branching strategy for your team based on team size, release cadence, and CI/CD maturity.
95
96Team characteristics -> What's your situation?
97 ├─ Small team (1-5 devs) + Continuous deployment + High CI/CD maturity?
98 │ └─ GitHub Flow (main + feature branches)
99 │
100 ├─ Medium team (5-15 devs) + Continuous deployment + High CI/CD maturity?
101 │ └─ Trunk-Based Development (main + short-lived branches)
102 │
103 ├─ Large team (15+ devs) + Continuous deployment + Very high CI/CD maturity?
104 │ └─ Trunk-Based + Feature Flags (progressive rollout)
105 │
106 ├─ Scheduled releases + Medium CI/CD maturity?
107 │ └─ GitFlow (main + develop + release branches)
108 │
109 └─ Multiple versions + Low-Medium CI/CD maturity?
110 └─ GitFlow (long-lived release branches)
111```
112
113## Navigation: Core Workflows
114
115### Branching Strategies
116
117**[Branching Strategies Comparison](references/branching-strategies.md)** - Comprehensive guide to choosing and implementing branching strategies
118
119- GitHub Flow (recommended for modern teams): Simple, continuous deployment
120- Trunk-Based Development (enterprise scale): Short-lived branches, daily merges
121- GitFlow (structured releases): Scheduled releases, multiple versions
122- Decision matrix: Team size, release cadence, CI/CD maturity
123- Migration paths between strategies
124
125### Pull Request Best Practices
126
127**[PR Best Practices Guide](references/pr-best-practices.md)** - Effective code reviews and fast PR cycles
128
129- PR size guidelines: keep PRs reviewable (often 200-400 LOC works well; split larger changes)
130- Review categories: BLOCKER, WARNING, NITPICK
131- Review etiquette: Collaborative feedback, code examples
132- PR description templates: What, Why, How, Testing
133- Data-driven insights on review efficiency
134
135### Commit Conventions
136
137**[Conventional Commits Standard](references/commit-conventions.md)** - Commit message formats and semantic versioning integration
138
139- Conventional commit format: `type(scope): description`
140- Commit types: feat, fix, BREAKING CHANGE, refactor, docs
141- SemVer automation: Auto-bump versions from commits
142- Changelog generation: Automated from commit history
143- Tools: commitlint, semantic-release, standard-version
144
145---
146
147## Navigation: Advanced Techniques
148
149### Stacked Diffs
150
151**[Stacked Diffs Implementation](references/stacked-diffs-guide.md)** - Platform-specific workflows and team adoption
152
153- What are stacked diffs: Break large features into reviewable chunks
154- When to use: Features > 500 lines, complex refactoring
155- GitLab native support: MR chains
156- GitHub with Graphite: CLI-based stacking
157- Benefits: 60% faster review cycles, better quality
158
159### Interactive Rebase
160
161**[Interactive Rebase & History Cleanup](references/interactive-rebase-guide.md)** - Maintain clean commit history
162
163- Auto-squash workflow: `fixup!` and `squash!` commits
164- Interactive rebase commands: pick, reword, edit, squash, fixup, drop
165- Splitting commits: Break large commits into focused changes
166- Reordering commits: Logical commit history
167- Best practices: Never rebase public branches
168
169### Conflict Resolution
170
171**[Conflict Resolution Techniques](references/conflict-resolution.md)** - Merge strategies and conflict handling
172
173- Resolution strategies: `--ours`, `--theirs`, manual merge
174- Rebase vs merge: When to use each
175- Merge tool setup: VS Code, Meld, custom tools
176- Conflict markers: Understanding `<<<<<<<`, `=======`, `>>>>>>>`
177- Prevention strategies: Frequent rebasing, small PRs
178
179---
180
181## Navigation: Automation & Quality
182
183### Automated Quality Gates
184
185**[Automated Quality Gates](references/automated-quality-gates.md)** - CI/CD pipelines and quality enforcement
186
187- Essential gates: Tests, coverage, linting, security scans
188- Advanced gates: Performance benchmarks, bundle size, a11y checks
189- GitHub Actions workflows: Complete PR checks pipeline
190- GitLab CI pipelines: MR quality gates
191- Pre-commit hooks: Husky + lint-staged setup
192- Quality metrics thresholds: Coverage 80%, complexity < 10
193
194### Validation Checklists
195
196**[Validation Checklists](references/validation-checklists.md)** - Pre-PR, pre-merge, pre-release checklists
197
198- Before creating PR: Code quality, commit hygiene, testing
199- Before merging PR: Review process, CI/CD checks, final verification
200- Before releasing: Pre-release testing, version management, documentation
201- Post-deployment: Immediate verification, monitoring, tasks
202- Hotfix checklist: Critical bug fast-track process
203
204### Release Management
205
206**[Release Management](references/release-management.md)** - Versioning and deployment workflows
207
208- Semantic versioning: MAJOR.MINOR.PATCH
209- Manual release workflow: GitFlow release branches
210- Automated releases: semantic-release automation
211- Hotfix workflow: Emergency patches
212- Changelog generation: Keep a Changelog format
213- Release checklists: Pre-release, release day, post-release
214
215---
216
217## Navigation: AI Agent Workflows
218
219### AI Agent Worktrees
220
221**[AI Agent Worktrees](references/ai-agent-worktrees.md)** - Worktree isolation patterns for AI coding agents
222
223- When to use worktrees with agents (decision table)
224- Directory conventions (`.worktrees/`, global paths, `.gitignore`)
225- Agent-specific patterns: Claude Code, Codex, Aider, Copilot Workspace
226- Parallel agent execution: one worktree per agent, disjoint file ownership
227- Safety: lock contention, conflict detection, cross-agent file guards
228- Cleanup lifecycle: removal, pruning, batch cleanup scripts
229
230---
231
232## Navigation: Learning & Troubleshooting
233
234### Monorepo Workflows
235
236**[Monorepo Workflows](references/monorepo-workflows.md)** - Git patterns for monorepo repositories
237
238- Trunk-based branching for monorepos
239- Sparse checkout and partial clone
240- Affected-only CI (Nx, Turborepo, Bazel)
241- CODEOWNERS per package/directory
242- Monorepo vs polyrepo decision table
243
244### Git Hooks Automation
245
246**[Git Hooks Automation](references/git-hooks-automation.md)** - Pre-commit, commit-msg, pre-push hooks
247
248- Husky v9+ and lefthook setup
249- lint-staged and commitlint integration
250- Custom hooks (gitleaks, file size limits, branch naming)
251- Team distribution strategies
252
253### Git Bisect Debugging
254
255**[Git Bisect Debugging](references/git-bisect-debugging.md)** - Regression hunting with git bisect
256
257- Manual and automated bisect workflows
258- Writing bisect test scripts
259- Handling merge commits, log and replay
260
261### Common Mistakes
262
263**[Common Mistakes & Fixes](references/common-mistakes.md)** - Learn from common pitfalls
264
265- Large unfocused PRs -> Split into stacked diffs
266- Vague commit messages -> Use conventional commits
267- Rewriting public history -> Never rebase main
268- Ignoring review comments -> Address all feedback
269- Committing secrets -> Use environment variables
270- Force push dangers -> Use `--force-with-lease`
271
272## Decision Tables
273
274### When to Use Each Branching Strategy
275
276| Requirement | GitHub Flow | Trunk-Based | GitFlow |
277|-------------|-------------|-------------|---------|
278| Continuous deployment | [OK] Best | [OK] Best | [FAIL] Poor |
279| Scheduled releases | [WARNING] OK | [WARNING] OK | [OK] Best |
280| Multiple versions | [FAIL] Poor | [FAIL] Poor | [OK] Best |
281| Small team (< 5) | [OK] Best | [WARNING] OK | [FAIL] Overkill |
282| Large team (> 15) | [WARNING] OK | [OK] Best | [WARNING] OK |
283| Fast iteration | [OK] Best | [OK] Best | [FAIL] Poor |
284
285### PR Size vs Review Time
286
287| LOC | Review Time | Bug Detection | Recommendation |
288|-----|-------------|---------------|----------------|
289| < 50 | < 10 min | High | [OK] Ideal for hotfixes |
290| 50-200 | 10-30 min | High | [OK] Ideal for features |
291| 200-400 | 30-60 min | Medium-High | [OK] Acceptable |
292| 400-1000 | 1-2 hours | Medium | [WARNING] Consider splitting |
293| > 1000 | > 2 hours | Low | [FAIL] Always split |
294
295## Do / Avoid
296
297### GOOD: Do
298
299- Keep PRs under 400 lines (200-400 optimal)
300- Use conventional commit messages
301- Rebase before opening PR (clean history)
302- Require at least one approval before merge
303- Run CI checks on every PR
304- Use stacked diffs for large features (>500 LOC)
305- Squash WIP commits before merge
306- Use `--force-with-lease` (not `--force`)
307
308### BAD: Avoid
309
310- Long-lived feature branches (>3 days)
311- Merging without review
312- Rebasing public/shared branches
313- Force pushing to main/master
314- Committing secrets (even "temporarily")
315- Large monolithic PRs (>1000 lines)
316- Vague commit messages ("fix", "update")
317- Skipping CI to merge faster
318
319## Anti-Patterns
320
321| Anti-Pattern | Problem | Fix |
322|--------------|---------|-----|
323| **Long-lived branches** | Merge conflicts, stale code | Trunk-based, short branches |
324| **Unreviewed merges** | Bugs reach production | Branch protection rules |
325| **Rebasing main** | History corruption | Never rebase public branches |
326| **1000+ LOC PRs** | Poor review quality | Stacked diffs, split PRs |
327| **"fix" commits** | Unclear history | Conventional commits |
328| **No CI gates** | Broken main | Required status checks |
329| **Secrets in history** | Security breach | Pre-commit hooks, gitleaks |
330
331## Repository Baseline (Security + Reliability)
332
333Set these repo defaults before scaling a team:
334
335- **Branch protection**: require PRs to `main` (no direct pushes), require status checks, require up-to-date branch on merge.
336- **Review gates**: require approvals; enforce CODEOWNERS for sensitive paths (auth, payments, infra, prod configs).
337- **History policy**: pick merge strategy (squash vs merge commits) and make it consistent; document exceptions.
338- **Signed changes**: require signed commits and signed tags for releases (team-specific key management).
339- **Secret prevention**: local pre-commit + server-side secret scanning/push protection; rotate on incident.
340- **Merge safety**: use merge queue (or equivalent) for busy repos to keep `main` green under high concurrency.
341- **Cost control**: cache dependencies/builds; run heavy jobs conditionally; cap CI minutes for untrusted forks.
342
343Template: [assets/pull-requests/pr-template.md](assets/pull-requests/pr-template.md)
344Guide: [assets/template-git-workflow-guide.md](assets/template-git-workflow-guide.md)
345
346## Security-Sensitive Changes
347
348For security-related git operations, see [dev-git-commit-message/assets/template-security-commits.md](../dev-git-commit-message/assets/template-security-commits.md):
349
350- Secrets detection with pre-commit hooks
351- Handling accidental secret commits
352- Security commit metadata (CVE, CVSS)
353- Branch protection for security-sensitive code
354
355## Optional: AI/Automation
356
357> **Note**: AI tools assist but cannot replace human judgment for merge decisions.
358
359- **PR summarization** - Generate description from commits
360- **Change risk labeling** - Flag high-risk files (auth, payments)
361- **Review suggestions** - Identify potential reviewers
362
363### Bounded Claims
364
365- AI summaries need human verification
366- Risk labels are suggestions, not guarantees
367- Merge decisions always require human approval
368
369---
370
371## Related Skills
372
373- [Software Code Review](../software-code-review/SKILL.md) - Code review standards and techniques
374- [Quality Debugging](../qa-debugging/SKILL.md) - Git bisect, debugging workflows
375- [DevOps Platform Engineering](../ops-devops-platform/SKILL.md) - CI/CD pipelines, automation
376- [Software Testing & Automation](../qa-testing-strategy/SKILL.md) - Test-driven development, coverage gates
377- [Documentation Standards](../docs-codebase/SKILL.md) - Changelog formats, documentation workflows
378- [Git Commit Message](../dev-git-commit-message/SKILL.md) - Commit message conventions, security commits
379
380## Usage Notes
381
382**For Claude Code**:
383
384- Recommend GitHub Flow for most modern teams (simple, effective)
385- Suggest stacked diffs for features > 500 lines
386- Always validate commit messages against conventional commit format
387- Check PR size - warn if > 400 lines, block if > 1000 lines
388- Reference assets/ for copy-paste ready configurations
389- Use references/ for deep-dive implementation guidance
390
391**Progressive Disclosure**:
392
3931. Start with Quick Reference for fast lookups
3942. Use Decision Tree for choosing strategies
3953. Navigate to specific resources for detailed implementation
3964. Reference templates for production-ready configurations
3975. Check validation checklists before PR/merge/release
398
399---
400
401## Quick Command Reference
402
403**Common Operations**:
404
405```bash
406# Rebase feature branch
407git fetch origin && git rebase origin/main
408
409# Interactive rebase last 3 commits
410git rebase -i HEAD~3
411
412# Squash all commits in branch
413git rebase -i $(git merge-base HEAD main)
414
415# Force push safely
416git push --force-with-lease origin feature-branch
417
418# Undo last commit (keep changes)
419git reset --soft HEAD~1
420
421# Cherry-pick specific commit
422git cherry-pick abc123
423
424# Stash changes
425git stash push -m "WIP: implementing feature X"
426git stash pop
427```
428
429**Conflict Resolution**:
430
431```bash
432# Pull latest with rebase
433git pull --rebase origin main
434
435# Use visual merge tool
436git mergetool
437
438# Accept their changes
439git checkout --theirs <file>
440
441# Accept your changes
442git checkout --ours <file>
443```
444
445## Trend Awareness Protocol
446
447IMPORTANT: When users ask recommendation questions about Git workflows, branching strategies, or collaboration tools, verify current trends via web search (and/or the links in `data/sources.json`) before answering.
448
449### Trigger Conditions
450
451- "What's the best Git workflow for [team size/use case]?"
452- "What should I use for [branching/PR management]?"
453- "What's the latest in Git collaboration?"
454- "Current best practices for [branching/code review]?"
455- "Is [GitFlow/Trunk-Based] still relevant in 2026?"
456- "[GitHub Flow] vs [Trunk-Based] vs [GitFlow]?"
457- "Best PR stacking tool?"
458
459### Required Searches
460
4611. Search: `"Git workflow best practices 2026"`
4622. Search: `"[specific strategy] vs alternatives 2026"`
4633. Search: `"Git collaboration trends January 2026"`
4644. Search: `"[branching/PR tools] comparison 2026"`
465
466### What to Report
467
468After searching, provide:
469
470- **Current landscape**: What Git workflows/tools are popular NOW
471- **Emerging trends**: New collaboration patterns, tools, or practices gaining traction
472- **Deprecated/declining**: Strategies/tools losing relevance or support
473- **Recommendation**: Based on fresh data, not just static knowledge
474
475### Example Topics (verify with fresh search)
476
477- Branching strategies (Trunk-Based, GitHub Flow, GitFlow)
478- PR stacking tools (Graphite, git-stack, Stacked PRs)
479- Merge queue implementations (GitHub, GitLab)
480- Code review platforms and automation
481- Conventional commits and changelog tools
482- Git hosting platform features (GitHub, GitLab, Bitbucket)
483- AI-assisted Git workflows
484
485## Fact-Checking
486
487- Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
488- Prefer primary sources; report source links and dates for volatile information.
489- If web access is unavailable, state the limitation and mark guidance as unverified.