Token导航 LogoToken导航

Agent Skill · 研究检索

git-workflow(Git 工作流)

git-workflow 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

git-workflow 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证为 MIT,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 43,099。

总安装 1,011周安装 43GitHub Stars 59下载 354核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:git-workflow(Git 工作流)
来源仓库:https://github.com/vasilyu1983/ai-agents-public
仓库路径:skills/git-workflow
安装命令:
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill git-workflow
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill git-workflow

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

git-workflow 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词、任务场景或来源线索快速定位候选结果。它可辅助从文档中提取内容、匹配字段或过滤无关信息,提升信息获取效率。

通过 npx skills add 命令从指定仓库安装,具体用法需结合 README 进一步确认。安装前建议检查权限范围和维护状态,避免触发不必要的联网或文件操作。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/git-workflow

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/vasilyu1983/ai-agents-public --skill git-workf…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

git-workflow 怎么安装?

在终端执行 npx skills add https://github.com/vasilyu1983/ai-agents-public --skill git-workflow。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

git-workflow 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

git-workflow 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

git-workflow 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

git-workflow 用的人多吗?

公开数据是累计安装 1,011 次,近一周安装 43 次,下载 354 次,GitHub 59 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

git-workflow 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
git-workflow

Git 工作流 · 本页

1,01159只读MIT有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

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

  1. Identify constraints (team size, release cadence, CI maturity, compliance).
  2. Choose a branching strategy using the decision tree.
  3. Apply the baseline repo settings (branch protection, approvals, checks, merge strategy).
  4. Use the relevant reference doc for implementation details.
  5. If asked "best practice in 2026", verify via web search using data/sources.json as a starting source list.

Quick Reference

TaskTool/CommandWhen to UseReference
Create feature branchgit switch -c feat/name mainStart new workBranching Strategies
Create feature worktreegit worktree add../wt-feature -b feature/name origin/devIsolate one feature per branchBranching Strategies
Squash WIP commitsgit rebase -i HEAD~3Clean up before PRInteractive Rebase
Conventional commitgit commit -m "feat: add feature"All commitsCommit Conventions
Force push safelygit push --force-with-leaseAfter rebaseCommon Mistakes
Resolve conflictsgit mergetoolMerge conflictsConflict Resolution
Create stacked PRsgt create stack-name (Graphite)Large featuresStacked Diffs
Auto-generate changelognpx standard-versionBefore releaseRelease Management
Run quality gatesGitHub Actions / GitLab CIEvery PRAutomated Quality Gates

AI Agent Feature Loop

For AI-assisted engineering, prefer this default loop:

  1. Create one worktree per feature branch.
  2. Implement scoped changes only for that feature.
  3. Run repository quality gate(s) before PR.
  4. Open one focused PR to the integration branch.

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.

  1. Working tree cleanliness:
  • git status --porcelain
  • If non-empty, decide explicitly: commit, stash, or abort branch switch.
  1. 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.
  1. Branch switch guard:
  • Do not checkout/switch when local changes would be overwritten.
  • Commit/stash intentionally; avoid accidental context loss.
  1. Merge conflict protocol:
  • On conflict, stop new edits, resolve conflict file-by-file, rerun relevant tests, then complete merge commit.
  1. 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: 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

RequirementGitHub FlowTrunk-BasedGitFlow
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

LOCReview TimeBug DetectionRecommendation
< 50< 10 minHigh[OK] Ideal for hotfixes
50-20010-30 minHigh[OK] Ideal for features
200-40030-60 minMedium-High[OK] Acceptable
400-10001-2 hoursMedium[WARNING] Consider splitting
> 1000> 2 hoursLow[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-PatternProblemFix
Long-lived branchesMerge conflicts, stale codeTrunk-based, short branches
Unreviewed mergesBugs reach productionBranch protection rules
Rebasing mainHistory corruptionNever rebase public branches
1000+ LOC PRsPoor review qualityStacked diffs, split PRs
"fix" commitsUnclear historyConventional commits
No CI gatesBroken mainRequired status checks
Secrets in historySecurity breachPre-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 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:

  1. Start with Quick Reference for fast lookups
  2. Use Decision Tree for choosing strategies
  3. Navigate to specific resources for detailed implementation
  4. Reference templates for production-ready configurations
  5. 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

  1. Search: "Git workflow best practices 2026"
  2. Search: "[specific strategy] vs alternatives 2026"
  3. Search: "Git collaboration trends January 2026"
  4. 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

平台分布

Claude Code

29.58%
按下载量换算105

Cursor

24.5%
按下载量换算87

Gemini CLI

16.27%
按下载量换算58

Antigravity

13.66%
按下载量换算48

Codex

8.82%
按下载量换算31

trae

3.4%
按下载量换算12

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。

继续浏览同类 Skills