name: Git 工作流与最佳实践 description: 专家级版本控制实践框架，包括分支策略、提交约定、拉取请求流程和发布管理，适用于协作开发。

Git 工作流与最佳实践

概述

Git 工作流包括在协作开发环境中有效使用 Git 的实践、模式和策略。这个技能提供了关于分支管理、提交约定、拉取请求流程、合并策略、标记、发布和 Git 配置的全面指导，以维护清晰的历史记录、促进协作并支持可靠部署。

为什么重要

促进协作：清晰的工作流和约定允许团队协作而不互相干扰
减少合并冲突：适当的分支和集成策略最小化冲突并提供清晰的解决路径
维护清晰历史：有意义的提交和适当的合并创建可读、可追溯的历史
支持可靠发布：语义化版本控制和标记实现可预测、受控的部署，具备回滚能力
加速新成员融入：清晰的提交历史和文档化工作流帮助新团队成员理解项目结构
启用代码恢复：适当的分支和标记允许轻松识别和恢复损坏的部署

核心概念

1. 分支命名约定

一致的分支前缀用于不同目的：

feature/：新功能和增强（例如，feature/user-authentication）
bugfix/：非紧急错误修复（例如，bugfix/login-validation-error）
hotfix/：紧急生产修复（例如，hotfix/payment-crash）
release/：发布准备和部署（例如，release/v2.1.0）
docs/：文档更新（例如，docs/api-reference）
refactor/：代码重构，无功能更改（例如，refactor/user-service）
test/：测试添加或修复（例如，test/payment-integration）
chore/：维护任务和依赖项（例如，chore/update-dependencies）

2. 提交消息格式

Conventional Commits 规范，用于清晰、结构化的提交消息：

格式：<type>(<scope>): <subject>

类型：

feat：新功能
fix：错误修复
docs：仅文档
style：格式化，无代码更改
refactor：代码重构
test：添加或更新测试
chore：维护、依赖项
perf：性能改进
ci：CI/CD 更改
build：构建系统更改
revert：撤销先前提交

主题规则：

使用命令式语气（“添加功能”而非“添加了功能”）
首字母大写
最多 50 个字符
引用相关问题和票号

3. 分支策略

分支管理模型：

Git Flow：用于计划发布的长期分支

GitHub Flow：用于持续部署的短期功能分支
基于主干的开发：单个主分支与短期功能分支
发布分支：用于发布准备的专用分支

4. 拉取请求流程

代码集成的标准工作流：

作者准备：自审代码，创建带有清晰描述和检查清单的 PR
审查执行：审查者检查代码，提供建设性反馈
处理反馈：作者回应评论并进行更改
合并或关闭：批准时合并 PR；拒绝或阻塞时关闭

5. 合并策略

集成代码的方法：

合并提交（–no-ff）：保留完整历史，推荐用于 Git Flow
压缩并合并：将提交合并为单一、清晰的历史
变基并合并：无合并提交的线性历史，适合清晰历史
快进合并：可能时快进，不创建合并提交

6. 发布管理

发布的语义化版本控制和标记：

语义化版本控制：MAJOR.MINOR.PATCH（例如，v1.0.0，v2.1.0）

发布标记：用于发布的带注释标记
发布工作流：分支准备、测试、标记、合并
变更日志：记录发布之间的更改

7. Git 钩子

自动化检查和验证：

预提交：提交前的代码检查、格式化、测试
提交消息：验证提交消息格式
预推送：推送前的测试、安全扫描
后合并：合并后的通知、部署

快速入门

选择分支策略：选择适当模型（Git Flow 用于计划发布，GitHub Flow 用于持续部署，基于主干用于快速迭代）
配置 Git 用户：设置姓名、电子邮件和常见操作的有用别名
设置 Git 钩子：安装和配置预提交、提交消息、预推送钩子进行验证
定义提交约定：为团队建立 Conventional Commits 或项目特定格式
创建分支工作流：根据所选策略文档化如何创建、切换、合并和删除分支
实施拉取请求流程：定义 PR 模板、审查检查清单、批准要求和合并策略
配置 CI/CD 集成：设置自动化检查（代码检查、测试、安全扫描）和部署管道
建立发布流程：定义语义化版本控制、标记工作流和变更日志生成
培训团队：教育团队工作流、钩子和最佳实践
监控和改进：跟踪指标如合并冲突率、PR 周转时间和部署频率；迭代流程

# 配置 Git 用户
git config --global user.name "您的姓名"
git config --global user.email "您的@邮箱.com"
git config --global alias.co checkout "checkout"
git config --global alias.br branch "branch"
git config --global alias.ci "commit -m 'chore(ci): '"

# 安装 pre-commit
pip install pre-commit
pre-commit install

# 配置 commitlint（Conventional Commits）
npm install -g @commitlint/cli
echo "npx --no @commitlint --edit \$@" > .husky/commit-msg

生产检查清单

[ ] 分支命名约定定义并文档化
[ ] 提交消息格式建立（Conventional Commits 或项目特定）
[ ] Git 钩子配置和安装（预提交、提交消息、预推送、后合并）
[ ] CI/CD 管道配置，包括代码检查、测试和安全扫描
[ ] 分支保护规则配置（要求审查、状态检查、限制谁可以推送）
[ ] 拉取请求模板创建，用于一致描述
[ ] 审查检查清单定义，包括代码质量、安全、性能、测试和文档
[ ] 合并策略定义（合并、压缩、变基），并指导何时使用每种
[ ] 发布工作流建立（语义化版本控制、标记、变更日志生成）
[ ] 热修复流程定义，用于紧急生产修复
[ ] 团队培训完成，关于 Git 工作流和最佳实践
[ ] Git 文档创建并可访问团队

反模式

过度设计工作流：复杂的分支策略（如 Git Flow）对于小团队或持续部署不必要
不遵循提交约定：不一致的提交消息使历史不可搜索且失去上下文
跳过拉取请求审查：未经审查批准 PR 导致错误和技术债务
强制推送：强制推送分支覆盖历史，导致混淆和数据丢失风险
不保护主分支：允许直接推送到主/主分支而无审查或检查，导致生产代码损坏
忽略冲突：不及时妥善解决冲突，阻碍其他团队成员
无 Git 钩子：缺少自动化验证导致构建损坏、不良提交和安全漏洞
变基共享分支：变基他人正在工作的分支导致冲突和工作丢失
不标记发布：缺少版本标记使回滚不可能，并造成部署版本混淆
文档不佳：缺少 Git 工作流文档导致不一致实践和融入摩擦

集成点

Git 平台：GitHub、GitLab、Bitbucket、Azure DevOps 用于托管仓库
Git 客户端：GitKraken、SourceTree、VS Code Git 集成增强 Git 体验
Git 钩子：Husky、pre-commit、commitlint 用于 Git 自动化
代码检查工具：ESLint、Prettier、Black、isort 用于代码格式化
CI/CD 平台：GitHub Actions、GitLab CI、Azure Pipelines、Jenkins 用于自动化管道
发布工具：semantic-release、standard-version、conventional-changelog 用于自动化版本控制和变更日志生成
文档：Git 文档、项目 README 和贡献指南用于团队融入
code-review 用于在 PR 中审查 Git 历史和提交
technical-debt-management 用于管理 Git 相关债务（复杂历史、合并冲突）

进一步阅读

Pro Git 书籍 - 全面的 Git 文档
GitHub Flow - GitHub 的工作流指南
Git Flow - Git Flow 分支模型
Conventional Commits - 提交消息规范
语义化版本控制 - 版本控制规范（MAJOR.MINOR.PATCH）
Husky - Git 钩子简化
lint-staged - 在暂存文件上运行代码检查
commitlint - 检查提交消息