SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场git-workflow

git-workflow

编程与开发

查看项目

更新于 10-14 08:37

技能介绍

用途

Git Workflow 是一套围绕 Git 使用规范的技能指南，目标是在撰写提交信息、创建分支、搭建 Git 工作流、评审拉取请求以及维护 Git 历史等环节中，提供可遵循的规则，从而维护干净、有用的 Git 提交历史。它适用于这些具体活动：写提交信息、创建分支、配置 Git 工作流、审查 PR、维护历史记录。

规则分类与优先级

规则按优先级分为五个类别，并以固定前缀组织规则文件：

  1. Commit Messages（CRITICAL，前缀 commit-）：约定式提交、原子提交（一个逻辑变更）、命令式现在时、有意义且描述性的信息、为复杂变更添加正文、引用 issue/ticket、用 Husky + commitlint 强制规范。
  2. Branching Strategy（HIGH，前缀 branch-）：统一分支命名、功能分支工作流、保护主分支、保持分支短生命周期、删除已合并分支、发布分支策略、GitFlow 与 GitHub Flow 与 Trunk-Based 的对比、monorepo 的 Git 工作流。
  3. Pull Requests（HIGH，前缀 pr-）：保持 PR 小而聚焦、编写清晰描述、请求合适的评审者、确保 CI 通过、在合适时压缩提交、使用草稿 PR 处理进行中的工作与早期反馈。
  4. History Management（MEDIUM，前缀 history-）：rebase 与 merge 的取舍、避免向共享分支强制推送、保持历史干净、用标签标记发布、用 git worktree 处理多分支。
  5. Collaboration（MEDIUM，前缀 collab-）：有效的代码评审、处理合并冲突、沟通变更、.gitignore 最佳实践。

主要能力与规范要点

提交信息（Conventional Commits）

格式为 <type>(<scope>): <subject>，可附正文与页脚。类型包括 feat（新功能）、fix（缺陷修复）、docs（仅文档）、style（格式，无代码变更）、refactor（非功能/修复的代码变更）、perf（性能优化）、test（新增/更新测试）、chore（维护、依赖）、ci（CI/CD 变更）、build（构建系统变更）、revert（回滚先前提交）。

文档给出正例，如 feat(auth): add password reset functionality、fix(cart): resolve quantity update race condition；也给出反例，如 fix bug、update、WIP、changes。带正文与页脚的示例中包含 Closes #123 与 BREAKING CHANGE: 声明。

原子提交与提交节奏

反对一次提交包含多个变更（如“Add login, fix header, update deps”），主张每个变更单独提交；提倡小而频繁的提交（如依次添加商品到购物车、显示数量、移除商品、补测试），而非一次性提交“实现整个购物车”。

分支命名与工作流

主分支包括 main（生产就绪代码）与 develop（集成分支，可选）；支持分支包括 feature/、fix/、hotfix/、release/。正例命名如 feature/user-authentication、feature/JIRA-123-password-reset、fix/cart-total-calculation、hotfix/security-patch；反例如 new-feature、john-branch、test、temp。

工作流示例：git checkout main → git pull origin main → git checkout -b feature/user-profile → 开发提交 → git fetch origin → git rebase origin/main → git push -u origin feature/user-profile 并创建 PR。

拉取请求（PR）

PR 标题格式与提交类似：<type>(<scope>): <description>。文档给出 PR 描述模板，包含 Summary、Changes、Testing 清单、Screenshots（如有 UI 变更）、Related Issues（Closes #123 / Related to #456）与 Checklist（遵循约定、自审完成、测试新增/更新、文档更新）。强调保持 PR 小而聚焦，并给出拆分示例：依次为用户模型与迁移、注册端点、邮箱验证、登录/登出，而非一个 2000+ 行、50+ 文件的全量认证 PR。

历史管理

  • 功能分支使用 rebase 保持历史干净，向 main 集成时使用 merge（--no-ff）保留上下文；
  • 严禁对共享分支强制推送，文档示例为 git push --force origin main（标注 NEVER DO THIS）；自己分支可用 git push --force-with-lease；
  • 交互式 rebase（git rebase -i HEAD~5）可用 pick/squash 清理提交；
  • 冲突处理：rebase 中解决冲突后 git add file.ts 与 git rebase --continue，必要时 git rebase --abort；
  • 语义化版本标签：git tag -a v1.0.0 -m "Release version 1.0.0"、git push origin v1.0.0，格式包括 v1.0.0、v1.0.0-beta.1、v1.0.0-rc.1。

Git Hooks 与配置

.pre-commit 示例运行 npm run lint 与 npm run test:unit；.husky/commit-msg 运行 npx commitlint --edit $1。commitlint 配置示例继承 @commitlint/config-conventional，并设定 type-enum、subject-max-length 为 72、body-max-line-length 为 100。

.gitignore 与常用命令

.gitignore 实践覆盖依赖（node_modules/、vendor/）、构建产物（dist/、build/、.next/）、环境文件（.env 等）、IDE（.idea/、.vscode/）、操作系统文件（.DS_Store、Thumbs.db）、日志、覆盖率与缓存。常用命令部分列出查看历史、查看变更、撤销提交（保留改动）、丢弃本地改动、stash、cherry-pick、blame、搜索提交等。

使用方式

可按规则文件阅读详细说明，例如 rules/commit-conventional-format.md、rules/branch-naming-convention.md、rules/pr-small-focused.md。在评审 Git 实践时，文档规定输出格式为 [category] Description of issue or suggestion，示例：

  • [commit] Use imperative mood: "Add feature" not "Added feature"
  • [branch] Branch name 'test' should follow pattern: feature/description
  • [pr] PR is too large (50+ files), consider splitting

参考资料与可借鉴项目

文档列出 Git 官方文档、Pro Git Book、Conventional Commits、GitHub Flow、How to Write a Git Commit Message、Google Code Review Practices；并建议参考具有良好 Git 实践的项目：Linux Kernel、React、Vue.js、TypeScript、Next.js。

适用场景与限制

适用场景为日常提交规范、分支与发布流程设计、PR 评审与历史维护。文档声明兼容 Git 2.0+ 以及 GitHub、GitLab、Bitbucket、Azure DevOps；推荐工具为 Git、GitHub CLI、Commitlint、Husky、Semantic Release。技能版本为 1.2.0，最后更新 2026-03-08，共 31 条规则、5 个类别。授权方式为 MIT License，文档注明该技能按“现状”提供，用于教育与开发目的。注意事项：文档中关于 rebase 时使用 --force-with-lease 的说明限定为“仅限你自己的分支”。