Back to Details

git-pr-workflows-git-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Complete Git Workflow with Multi-Agent Orchestration

基于多Agent编排的完整Git工作流

Orchestrate a comprehensive git workflow from code review through PR creation, leveraging specialized agents for quality assurance, testing, and deployment readiness. This workflow implements modern git best practices including Conventional Commits, automated testing, and structured PR creation.
[Extended thinking: This workflow coordinates multiple specialized agents to ensure code quality before commits are made. The code-reviewer agent performs initial quality checks, test-automator ensures all tests pass, and deployment-engineer verifies production readiness. By orchestrating these agents sequentially with context passing, we prevent broken code from entering the repository while maintaining high velocity. The workflow supports both trunk-based and feature-branch strategies with configurable options for different team needs.]
利用专门的Agent编排从代码审查到PR创建的完整Git工作流，涵盖质量保证、测试和部署就绪检查。该工作流采用现代Git最佳实践，包括Conventional Commits、自动化测试和结构化PR创建。
[扩展思考：该工作流协调多个专门的Agent，确保代码提交前的质量。code-reviewer Agent执行初始质量检查，test-automator确保所有测试通过，deployment-engineer验证生产就绪状态。通过按顺序编排这些Agent并传递上下文，我们可以防止有问题的代码进入代码库，同时保持高效的开发速度。该工作流支持基于主干和特性分支两种策略，可根据不同团队需求进行配置。]

Use this skill when

何时使用该技能

  • Working on complete git workflow with multi-agent orchestration tasks or workflows
  • Needing guidance, best practices, or checklists for complete git workflow with multi-agent orchestration
  • 处理基于多Agent编排的完整Git工作流相关任务或流程
  • 需要基于多Agent编排的完整Git工作流的指导、最佳实践或检查清单

Do not use this skill when

何时不使用该技能

  • The task is unrelated to complete git workflow with multi-agent orchestration
  • You need a different domain or tool outside this scope
  • 任务与基于多Agent编排的完整Git工作流无关
  • 需要该范围之外的其他领域或工具

Instructions

操作说明

  • Clarify goals, constraints, and required inputs.
  • Apply relevant best practices and validate outcomes.
  • Provide actionable steps and verification.
  • If detailed examples are required, open 
    resources/implementation-playbook.md
    .
  • 明确目标、约束条件和所需输入。
  • 应用相关最佳实践并验证结果。
  • 提供可操作的步骤和验证方法。
  • 如果需要详细示例，请打开
    resources/implementation-playbook.md
    。

Configuration

配置

Target branch: $ARGUMENTS (defaults to 'main' if not specified)
Supported flags:
  • --skip-tests
    : Skip automated test execution (use with caution)
  • --draft-pr
    : Create PR as draft for work-in-progress
  • --no-push
    : Perform all checks but don't push to remote
  • --squash
    : Squash commits before pushing
  • --conventional
    : Enforce Conventional Commits format strictly
  • --trunk-based
    : Use trunk-based development workflow
  • --feature-branch
    : Use feature branch workflow (default)
目标分支：$ARGUMENTS（未指定时默认为'main'）
支持的标志:
  • --skip-tests
    : 跳过自动化测试执行（谨慎使用）
  • --draft-pr
    : 将PR创建为草稿，用于进行中的工作
  • --no-push
    : 执行所有检查但不推送到远程仓库
  • --squash
    : 推送前合并提交
  • --conventional
    : 严格强制执行Conventional Commits格式
  • --trunk-based
    : 使用基于主干的开发工作流
  • --feature-branch
    : 使用特性分支工作流（默认）

Phase 1: Pre-Commit Review and Analysis

阶段1：提交前审查与分析

1. Code Quality Assessment

1. 代码质量评估

  • Use Task tool with subagent_type="code-reviewer"
  • Prompt: "Review all uncommitted changes for code quality issues. Check for: 1) Code style violations, 2) Security vulnerabilities, 3) Performance concerns, 4) Missing error handling, 5) Incomplete implementations. Generate a detailed report with severity levels (critical/high/medium/low) and provide specific line-by-line feedback. Output format: JSON with {issues: [], summary: {critical: 0, high: 0, medium: 0, low: 0}, recommendations: []}"
  • Expected output: Structured code review report for next phase
  • 使用Task工具，设置subagent_type="code-reviewer"
  • 提示词：“审查所有未提交的变更，检查代码质量问题。需检查：1）代码风格违规，2）安全漏洞，3）性能问题，4）缺失的错误处理，5）未完成的实现。生成包含严重级别（critical/high/medium/low）的详细报告，并提供具体的逐行反馈。输出格式：JSON，结构为{issues: [], summary: {critical: 0, high: 0, medium: 0, low: 0}, recommendations: []}”
  • 预期输出：供下一阶段使用的结构化代码审查报告

2. Dependency and Breaking Change Analysis

2. 依赖项与破坏性变更分析

  • Use Task tool with subagent_type="code-reviewer"
  • Prompt: "Analyze the changes for: 1) New dependencies or version changes, 2) Breaking API changes, 3) Database schema modifications, 4) Configuration changes, 5) Backward compatibility issues. Context from previous review: [insert issues summary]. Identify any changes that require migration scripts or documentation updates."
  • Context from previous: Code quality issues that might indicate breaking changes
  • Expected output: Breaking change assessment and migration requirements
  • 使用Task工具，设置subagent_type="code-reviewer"
  • 提示词：“分析变更内容：1）新依赖项或版本变更，2）API破坏性变更，3）数据库架构修改，4）配置变更，5）向后兼容性问题。参考上一阶段的审查上下文：[插入问题摘要]。识别任何需要迁移脚本或文档更新的变更。”
  • 参考上下文：可能指示破坏性变更的代码质量问题
  • 预期输出：破坏性变更评估结果和迁移需求

Phase 2: Testing and Validation

阶段2：测试与验证

1. Test Execution and Coverage

1. 测试执行与覆盖率

  • Use Task tool with subagent_type="unit-testing::test-automator"
  • Prompt: "Execute all test suites for the modified code. Run: 1) Unit tests, 2) Integration tests, 3) End-to-end tests if applicable. Generate coverage report and identify any untested code paths. Based on review issues: [insert critical/high issues], ensure tests cover the problem areas. Provide test results in format: {passed: [], failed: [], skipped: [], coverage: {statements: %, branches: %, functions: %, lines: %}, untested_critical_paths: []}"
  • Context from previous: Critical code review issues that need test coverage
  • Expected output: Complete test results and coverage metrics
  • 使用Task工具，设置subagent_type="unit-testing::test-automator"
  • 提示词：“执行修改代码的所有测试套件。运行：1）单元测试，2）集成测试，3）适用的话执行端到端测试。生成覆盖率报告并识别任何未测试的代码路径。基于审查问题：[插入critical/high级别问题]，确保测试覆盖问题区域。测试结果格式：{passed: [], failed: [], skipped: [], coverage: {statements: %, branches: %, functions: %, lines: %}, untested_critical_paths: []}”
  • 参考上下文：需要测试覆盖的关键代码审查问题
  • 预期输出：完整的测试结果和覆盖率指标

2. Test Recommendations and Gap Analysis

2. 测试建议与差距分析

  • Use Task tool with subagent_type="unit-testing::test-automator"
  • Prompt: "Based on test results [insert summary] and code changes, identify: 1) Missing test scenarios, 2) Edge cases not covered, 3) Integration points needing verification, 4) Performance benchmarks needed. Generate test implementation recommendations prioritized by risk. Consider the breaking changes identified: [insert breaking changes]."
  • Context from previous: Test results, breaking changes, untested paths
  • Expected output: Prioritized list of additional tests needed
  • 使用Task工具，设置subagent_type="unit-testing::test-automator"
  • 提示词：“基于测试结果[插入摘要]和代码变更，识别：1）缺失的测试场景，2）未覆盖的边缘情况，3）需要验证的集成点，4）需要的性能基准。按风险优先级生成测试实现建议。参考已识别的破坏性变更：[插入破坏性变更]。”
  • 参考上下文：测试结果、破坏性变更、未测试路径
  • 预期输出：按优先级排序的额外测试需求列表

Phase 3: Commit Message Generation

阶段3：提交消息生成

1. Change Analysis and Categorization

1. 变更分析与分类

  • Use Task tool with subagent_type="code-reviewer"
  • Prompt: "Analyze all changes and categorize them according to Conventional Commits specification. Identify the primary change type (feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert) and scope. For changes: [insert file list and summary], determine if this should be a single commit or multiple atomic commits. Consider test results: [insert test summary]."
  • Context from previous: Test results, code review summary
  • Expected output: Commit structure recommendation
  • 使用Task工具，设置subagent_type="code-reviewer"
  • 提示词：“分析所有变更并根据Conventional Commits规范进行分类。识别主要变更类型（feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert）和范围。针对变更：[插入文件列表和摘要]，确定应创建单个提交还是多个原子提交。参考测试结果：[插入测试摘要]。”
  • 参考上下文：测试结果、代码审查摘要
  • 预期输出：提交结构建议

2. Conventional Commit Message Creation

2. Conventional Commits格式消息创建

  • Use Task tool with subagent_type="llm-application-dev::prompt-engineer"
  • Prompt: "Create Conventional Commits format message(s) based on categorization: [insert categorization]. Format: <type>(<scope>): <subject> with blank line then <body> explaining what and why (not how), then <footer> with BREAKING CHANGE: if applicable. Include: 1) Clear subject line (50 chars max), 2) Detailed body explaining rationale, 3) References to issues/tickets, 4) Co-authors if applicable. Consider the impact: [insert breaking changes if any]."
  • Context from previous: Change categorization, breaking changes
  • Expected output: Properly formatted commit message(s)
  • 使用Task工具，设置subagent_type="llm-application-dev::prompt-engineer"
  • 提示词：“基于分类结果[插入分类]创建Conventional Commits格式的消息。格式：<type>(<scope>): <subject>，空行后是<body>解释变更内容和原因（而非实现方式），最后是<footer>，如有需要包含BREAKING CHANGE:。需包含：1）清晰的主题行（最多50字符），2）详细的正文解释理由，3）关联的问题/工单，4）适用的话包含共同作者。参考变更影响：[插入破坏性变更（如有）]。”
  • 参考上下文：变更分类、破坏性变更
  • 预期输出：格式正确的提交消息

Phase 4: Branch Strategy and Push Preparation

阶段4：分支策略与推送准备

1. Branch Management

1. 分支管理

  • Use Task tool with subagent_type="cicd-automation::deployment-engineer"
  • Prompt: "Based on workflow type [--trunk-based or --feature-branch], prepare branch strategy. For feature branch: ensure branch name follows pattern (feature|bugfix|hotfix)/<ticket>-<description>. For trunk-based: prepare for direct main push with feature flag strategy if needed. Current branch: [insert branch], target: [insert target branch]. Verify no conflicts with target branch."
  • Expected output: Branch preparation commands and conflict status
  • 使用Task工具，设置subagent_type="cicd-automation::deployment-engineer"
  • 提示词：“根据工作流类型[--trunk-based或--feature-branch]准备分支策略。对于特性分支：确保分支名称遵循模式(feature|bugfix|hotfix)/<ticket>-<description>。对于基于主干的工作流：准备直接推送到main分支，如有需要使用特性标志策略。当前分支：[插入分支]，目标分支：[插入目标分支]。验证与目标分支无冲突。”
  • 预期输出：分支准备命令和冲突状态

2. Pre-Push Validation

2. 推送前验证

  • Use Task tool with subagent_type="cicd-automation::deployment-engineer"
  • Prompt: "Perform final pre-push checks: 1) Verify all CI checks will pass, 2) Confirm no sensitive data in commits, 3) Validate commit signatures if required, 4) Check branch protection rules, 5) Ensure all review comments addressed. Test summary: [insert test results]. Review status: [insert review summary]."
  • Context from previous: All previous validation results
  • Expected output: Push readiness confirmation or blocking issues
  • 使用Task工具，设置subagent_type="cicd-automation::deployment-engineer"
  • 提示词：“执行最终的推送前检查：1）验证所有CI检查将通过，2）确认提交中无敏感数据，3）如需验证提交签名，4）检查分支保护规则，5）确保所有审查评论已处理。测试摘要：[插入测试结果]。审查状态：[插入审查摘要]。”
  • 参考上下文：所有之前的验证结果
  • 预期输出：推送就绪确认或阻塞问题

Phase 5: Pull Request Creation

阶段5：拉取请求（PR）创建

1. PR Description Generation

1. PR描述生成

  • Use Task tool with subagent_type="documentation-generation::docs-architect"
  • Prompt: "Create comprehensive PR description including: 1) Summary of changes (what and why), 2) Type of change checklist, 3) Testing performed summary from [insert test results], 4) Screenshots/recordings if UI changes, 5) Deployment notes from [insert deployment considerations], 6) Related issues/tickets, 7) Breaking changes section if applicable: [insert breaking changes], 8) Reviewer checklist. Format as GitHub-flavored Markdown."
  • Context from previous: All validation results, test outcomes, breaking changes
  • Expected output: Complete PR description in Markdown
  • 使用Task工具，设置subagent_type="documentation-generation::docs-architect"
  • 提示词：“创建全面的PR描述，包括：1）变更摘要（内容和原因），2）变更类型检查清单，3）测试执行摘要（来自[插入测试结果]），4）如有UI变更需包含截图/录屏，5）部署说明（来自[插入部署注意事项]），6）关联的问题/工单，7）破坏性变更部分（如有：[插入破坏性变更]），8）审查者检查清单。格式为GitHub风格的Markdown。”
  • 参考上下文：所有验证结果、测试输出、破坏性变更
  • 预期输出：完整的Markdown格式PR描述

2. PR Metadata and Automation Setup

2. PR元数据与自动化设置

  • Use Task tool with subagent_type="cicd-automation::deployment-engineer"
  • Prompt: "Configure PR metadata: 1) Assign appropriate reviewers based on CODEOWNERS, 2) Add labels (type, priority, component), 3) Link related issues, 4) Set milestone if applicable, 5) Configure merge strategy (squash/merge/rebase), 6) Set up auto-merge if all checks pass. Consider draft status: [--draft-pr flag]. Include test status: [insert test summary]."
  • Context from previous: PR description, test results, review status
  • Expected output: PR configuration commands and automation rules
  • 使用Task工具，设置subagent_type="cicd-automation::deployment-engineer"
  • 提示词：“配置PR元数据：1）根据CODEOWNERS分配合适的审查者，2）添加标签（类型、优先级、组件），3）关联相关问题，4）适用的话设置里程碑，5）配置合并策略（squash/merge/rebase），6）如所有检查通过则设置自动合并。参考草稿状态：[--draft-pr标志]。包含测试状态：[插入测试摘要]。”
  • 参考上下文：PR描述、测试结果、审查状态
  • 预期输出：PR配置命令和自动化规则

Success Criteria

成功标准

  • ✅ All critical and high-severity code issues resolved
  • ✅ Test coverage maintained or improved (target: >80%)
  • ✅ All tests passing (unit, integration, e2e)
  • ✅ Commit messages follow Conventional Commits format
  • ✅ No merge conflicts with target branch
  • ✅ PR description complete with all required sections
  • ✅ Branch protection rules satisfied
  • ✅ Security scanning completed with no critical vulnerabilities
  • ✅ Performance benchmarks within acceptable thresholds
  • ✅ Documentation updated for any API changes
  • ✅ 所有critical和high级别的代码问题已解决
  • ✅ 测试覆盖率保持或提升（目标：>80%）
  • ✅ 所有测试通过（单元测试、集成测试、端到端测试）
  • ✅ 提交消息遵循Conventional Commits格式
  • ✅ 与目标分支无合并冲突
  • ✅ PR描述包含所有必填部分
  • ✅ 满足分支保护规则
  • ✅ 安全扫描完成且无critical级漏洞
  • ✅ 性能基准在可接受范围内
  • ✅ 任何API变更的文档已更新

Rollback Procedures

回滚流程

In case of issues after merge:
  1. Immediate Revert: Create revert PR with 
    git revert <commit-hash>
  2. Feature Flag Disable: If using feature flags, disable immediately
  3. Hotfix Branch: For critical issues, create hotfix branch from main
  4. Communication: Notify team via designated channels
  5. Root Cause Analysis: Document issue in postmortem template
合并后出现问题时：
  1. 立即回滚：使用
    git revert <commit-hash>
    创建回滚PR
  2. 特性标志禁用：如使用特性标志，立即禁用
  3. 热修复分支：针对严重问题，从main分支创建热修复分支
  4. 沟通：通过指定渠道通知团队
  5. 根本原因分析：在事后分析模板中记录问题

Best Practices Reference

最佳实践参考

  • Commit Frequency: Commit early and often, but ensure each commit is atomic
  • Branch Naming: 
    (feature|bugfix|hotfix|docs|chore)/<ticket-id>-<brief-description>
  • PR Size: Keep PRs under 400 lines for effective review
  • Review Response: Address review comments within 24 hours
  • Merge Strategy: Squash for feature branches, merge for release branches
  • Sign-Off: Require at least 2 approvals for main branch changes
  • 提交频率：尽早并经常提交，但确保每个提交是原子性的
  • 分支命名：
    (feature|bugfix|hotfix|docs|chore)/<ticket-id>-<brief-description>
  • PR大小：PR代码行数保持在400行以下，以便有效审查
  • 审查响应：24小时内处理审查评论
  • 合并策略：特性分支使用squash合并，发布分支使用merge合并
  • 签署确认：main分支变更需要至少2个批准