‹ 首页

git-workflow

@developersglobal · 收录于 1 周前

Trunk-based development with atomic commits, clean history, and meaningful commit messages. Every commit should be deployable.

场景代码提交版本管理

适合你，如果希望团队遵循统一的 Git 工作流规范。

/ 下载安装
git-workflow.skill双击,或拖进 Claude 桌面版 / Cowork,即完成安装↓ .skill↓ .zip
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code~/.claude/skills/(项目级 .claude/skills/)
Codex CLI~/.codex/skills/
Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add developersglobal/ai-agent-skills/git-workflow
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- developersglobal/ai-agent-skills/git-workflow
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify developersglobal/ai-agent-skills/git-workflow
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
64GitHub stars
~575上下文体积 · 单文件
镜像托管

怎么用

技能原文 SKILL.md作者撰写 · MIT · f47f948
Overview

Git is not just a backup system — it's a communication tool. Clean git history enables fast debugging (git bisect), clear attribution, and safe reverts. This skill enforces atomic commits, meaningful messages, and trunk-based development.

When to Use
  • Before making any commit
  • When reviewing a PR's git history
  • When setting up a new project
Process
Step 1: Atomic Commits
  1. Each commit should represent ONE logical change — not a day's worth of work.
  2. A commit should be: independently deployable, independently revertable.
  3. Never commit "WIP" or partial implementations.

Verify: You could revert this commit without affecting adjacent functionality.

Step 2: Commit Message Format
  1. Follow Conventional Commits: ``` type(scope): short summary (max 72 chars)

Body: what changed and WHY (not how — the diff shows how).

Closes: #issue-number ```

  1. Types: feat, fix, docs, style, refactor, test, chore
  2. The summary is imperative mood: "Add feature" not "Added feature"

Verify: Message passes: feat|fix|docs|...(<scope>): <summary> format.

Step 3: Trunk-Based Development
  1. Work directly on main for small changes (<1 day of work).
  2. For larger features: short-lived feature branches (max 2 days), frequent merges to main.
  3. Never let a branch live more than 3 days without merging or rebasing.
  4. Use feature flags for incomplete features, not long-lived branches.

Verify: No branch is more than 2 days old without a merge/rebase plan.

Step 4: Pre-Commit Gates
  1. Before every commit: tests pass, linter passes, no secrets in diff.
  2. Use pre-commit hooks to enforce automatically.
Common Rationalizations (and Rebuttals)

| Excuse | Rebuttal | |--------|----------| | "I'll clean up the commits later" | You won't. Clean as you go. | | "The commit message doesn't matter" | It matters in 6 months when you're bisecting a production bug. | | "Feature branches protect main" | Long-lived branches cause merge nightmares. Trunk-based is safer. |

Verification
  • [ ] Commits are atomic and independently deployable
  • [ ] Commit messages follow Conventional Commits format
  • [ ] No long-lived branches (> 3 days)
  • [ ] Pre-commit hooks in place
References
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…