⚡

管理Git工作流Skill managing-git-workflows

此技能用于管理Git版本控制系统中的工作流，包括分支策略选择（如主干开发、GitHub Flow、GitFlow）、提交约定实施（如常规提交）、Git钩子设置（用于质量门控）、单仓库管理等，以提升团队协作效率、代码质量和自动化发布。关键词：Git工作流、分支策略、常规提交、Git钩子、单仓库管理、自动化版本控制、团队协作

DevOps 0 次安装 0 次浏览 更新于 3/23/2026

name: 管理Git工作流 description: 管理Git分支策略、提交约定和协作工作流。在主干开发、GitHub Flow或GitFlow之间选择时使用，实现常规提交以自动版本控制，设置Git钩子用于质量门控，或组织具有明确所有权的单仓库。

Git工作流

实现结构化的Git工作流，用于团队协作、代码质量和自动化发布。此技能涵盖分支策略、常规提交格式、Git钩子和单仓库管理模式。

何时使用此技能

使用此技能当：

  • 为新的项目或团队选择分支策略
  • 实现一致的提交消息格式
  • 设置Git钩子用于代码检查、测试或验证
  • 管理具有多个项目的单仓库
  • 建立代码审查工作流
  • 自动化版本控制和发布

快速决策：哪种分支策略？

主干开发

当团队拥有强大的CI/CD自动化、全面的测试覆盖率（80%以上）和频繁部署（每天或更多）时使用。短寿命分支在1天内合并。需要功能标志用于不完整功能。

最适合： 高速团队，具有成熟的DevOps实践（如Google、Facebook、Netflix）

GitHub Flow

用于具有持续部署的Web应用程序。主分支始终代表生产环境。适用于小型到中型团队（2-20名开发者）的简单PR工作流。

最适合： 初创公司、SaaS产品、开源项目

GitFlow

当同时支持多个生产版本、需要正式QA周期或遵循计划发布（每月、每季度）时使用。更复杂但结构化。

最适合： 企业软件、具有应用商店发布的移动应用、内部部署产品

关于详细分支模式示例，请参阅references/branching-strategies.md。

常规提交

结构化提交消息以自动版本控制和变更日志生成：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

常见类型：

  • feat - 新功能（次要版本更新：0.1.0）
  • fix - 错误修复（补丁版本更新：0.0.1）
  • docs - 仅文档
  • refactor - 代码重构，无功能更改
  • test - 添加或更新测试
  • chore - 维护任务

破坏性变更：

  • 在类型后添加!：feat!: 或 fix!:
  • 在脚注中添加BREAKING CHANGE:
  • 导致主版本更新（1.0.0）

示例：

git commit -m "feat(auth): 添加JWT令牌验证"
git commit -m "fix: 解决用户登录的竞态条件"
git commit -m "feat!: 重新设计认证API

BREAKING CHANGE: 认证端点现在需要API版本头部"

关于完整规范和工具设置，请参阅references/conventional-commits.md。

Git钩子用于质量门控

在关键工作流程点自动化代码质量检查：

pre-commit - 在提交创建前运行

  • 代码检查（ESLint、Prettier）
  • 格式化检查
  • 快速测试

commit-msg - 验证提交消息格式

  • 强制常规提交
  • 检查消息长度

pre-push - 在推送到远程前运行

  • 完整测试套件
  • 防止强制推送到受保护分支

使用Husky快速设置：

npm install --save-dev husky lint-staged @commitlint/cli @commitlint/config-conventional
npx husky init
npx husky add .husky/pre-commit "npx lint-staged"
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

关于完整钩子配置和示例，请参阅references/git-hooks-guide.md。

单仓库管理

构建工具选择

Nx - 最适合TypeScript/JavaScript单仓库

  • 依赖图分析
  • 影响命令（仅重建更改的项目）
  • 分布式缓存

Turborepo - 最适合Next.js/React应用程序

  • 快速增量构建
  • 远程缓存
  • 简单配置

稀疏检出 - 当不需要完整克隆时用于大型仓库

git sparse-checkout init --cone
git sparse-checkout set apps/web libs/ui-components

代码所有权

使用.github/CODEOWNERS定义所有权：

# 默认所有者
* @org/engineering

# 应用程序所有权
/apps/web/ @org/web-team
/apps/mobile/ @org/mobile-team

# 安全关键
/libs/auth/ @org/security-team @org/principal-engineers

关于详细单仓库模式，请参阅references/monorepo-patterns.md。

合并 vs 变基

合并提交

当保留完整历史重要时使用：

git checkout main
git merge feature-branch

何时： 多个开发者在功能分支上，希望看到集成点

压缩并合并

用于清晰、线性历史：

git checkout main
git merge --squash feature-branch
git commit -m "feat: 添加用户认证"

何时： 功能有多个WIP提交，希望清晰的主分支历史

变基

用于无合并提交的线性历史：

git checkout feature-branch
git rebase main

何时： 更新功能分支、单独工作、在PR前清理

⚠️ 永不变基： 公共分支（主分支、开发分支）或已推送并由他人使用的提交

代码审查工作流

拉取请求模板

创建.github/PULL_REQUEST_TEMPLATE.md：

## 描述
<!-- 变更的简要描述 -->

## 变更类型
- [ ] 错误修复
- [ ] 新功能
- [ ] 破坏性变更
- [ ] 文档更新

## 检查清单
- [ ] 代码遵循风格指南
- [ ] 自审代码
- [ ] 添加测试
- [ ] 更新文档
- [ ] 本地测试通过

分支保护规则

通过仓库设置强制质量门控：

  • 要求拉取请求审查（2+批准）
  • 要求状态检查（构建、测试、检查）
  • 要求在合并前分支保持最新
  • 限制强制推送和删除

关于完整代码审查设置，请参阅references/code-review-workflows.md。

分支命名约定

使用一致的命名以保持清晰：

  • feature/user-authentication - 新功能
  • bugfix/login-error - 错误修复
  • hotfix/critical-security-issue - 紧急生产修复
  • docs/api-documentation - 文档变更
  • refactor/database-layer - 代码重构

通过Git钩子验证分支名称（请参阅scripts/check-branch-name.sh）。

高级技术

拣选用于紧急修复

应用特定提交到其他分支：

git checkout main
git commit -m "fix: 解决关键安全问题"
# 提交哈希：a1b2c3d

git checkout release/1.5
git cherry-pick a1b2c3d

Git LFS用于大文件

跟踪大文件，与代码分开：

git lfs install
git lfs track "*.psd"
git lfs track "*.mp4"
git add .gitattributes

发布标签

标记生产发布：

git tag -a v1.2.0 -m "发布版本1.2.0"
git push origin v1.2.0

交互式变基

在PR前清理提交历史：

git rebase -i HEAD~3
# 压缩WIP提交、重写消息、重新排序提交

关于详细示例，请参阅examples/目录。

自动化发布工作流

将常规提交与CI/CD结合以自动化版本控制：

  1. 提交 - 遵循常规格式
  2. 分析 - Semantic Release分析提交类型
  3. 版本 - 确定主版本、次版本、补丁更新
  4. 变更日志 - 从提交自动生成
  5. 标签 - 创建Git标签
  6. 发布 - 部署到npm、GitHub发布等

请参阅examples/semantic-release-setup/以获取完整配置。

工具推荐

Git钩子：

  • Husky - 简化钩子管理（最流行）
  • lint-staged - 仅对暂存文件运行检查器（性能）

提交验证：

  • Commitlint - 强制常规提交
  • Semantic Release - 自动化版本控制

单仓库构建：

  • Nx - TypeScript/JavaScript（Google、AWS使用）
  • Turborepo - Next.js/React（Vercel）

大文件：

  • Git LFS - 存储大二进制文件

所有工具已通过Context7验证，具有高信任度（2025年12月）。

与其他技能集成

building-ci-pipelines - Git工作流触发CI/CD流水线，分支保护强制CI检查

writing-github-actions - GitHub Actions自动化工作流步骤（发布、PR检查）

infrastructure-as-code - IaC仓库需要结构化工作流，GitOps使用Git作为唯一真相源

testing-strategies - Git钩子强制执行测试要求，预推送运行测试套件

security-hardening - Git钩子防止秘密泄露，签名提交验证身份，CODEOWNERS强制安全审查

快速参考

主干开发工作流

git checkout -b feature/add-login main
git add .
git commit -m "feat: 添加登录表单组件"
git rebase origin/main  # 保持最新
git push origin feature/add-login
# PR → 合并 → 删除分支（在24小时内）

GitHub Flow工作流

git checkout -b feature/user-auth main
git commit -m "feat: 添加JWT认证"
git commit -m "test: 添加认证测试"
git push origin feature/user-auth
# 打开PR → 审查 → 合并 → 部署 → 删除分支

GitFlow工作流

# 功能
git checkout -b feature/user-profile develop
git commit -m "feat: 添加用户档案"
git checkout develop
git merge --no-ff feature/user-profile

# 发布
git checkout -b release/1.1.0 develop
git checkout main
git merge --no-ff release/1.1.0
git tag -a v1.1.0 -m "发布1.1.0"

# 紧急修复
git checkout -b hotfix/critical-bug main
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.1.1 -m "紧急修复1.1.1"

验证脚本

运行自动化检查：

  • scripts/validate-commit-msg.sh - 验证提交消息格式
  • scripts/check-branch-name.sh - 验证分支命名约定
  • scripts/setup-hooks.sh - 自动化钩子安装

直接执行脚本（无令牌）进行验证。