Git工作流简介

Git工作流是一套约定和最佳实践，用于规范团队如何使用Git进行协作开发。选择合适的工作流对于提高团队效率、减少冲突和维护代码质量至关重要。

为什么需要工作流？

虽然Git非常灵活，但没有标准化的工作流可能导致：

• 团队成员之间的混乱和不一致
• 频繁的合并冲突
• 难以追踪功能和修复
• 发布过程复杂且容易出错

一个好的工作流应该：

• 适合团队规模和项目特点
• 清晰定义开发、测试和发布过程
• 提供分支命名和管理的规范
• 支持并行开发和持续集成
• 平衡灵活性和规范性

图1: 常见Git工作流对比图

选择工作流的考虑因素

Git Flow工作流

Git Flow是由Vincent Driessen在2010年提出的一种工作流模型，特别适合有定期发布计划的项目。它定义了严格的分支结构和角色，为复杂项目提供了清晰的开发路径。

核心分支

• master（主分支）：仅包含发布版本的代码，永远处于可发布状态
• develop（开发分支）：包含最新开发代码，从此分支创建功能分支

支持分支

• feature/（功能分支）：用于开发新功能，从develop分支创建，完成后合并回develop
• release/（发布分支）：为发布准备的分支，允许小修复和元数据准备
• hotfix/（热修复分支）：用于紧急修复生产问题，从master创建，完成后合并到master和develop
• bugfix/（错误修复分支）：用于修复开发中的bug，从develop创建，修复后合并回develop

图2: Git Flow工作流分支示意图

Git Flow工作流程

# 安装Git Flow（macOS）
brew install git-flow-avh

# 初始化Git Flow（在Git仓库中）
git flow init

# 开始新功能
git flow feature start user-authentication

# 完成功能开发
git flow feature finish user-authentication

# 开始新功能
git checkout develop
git checkout -b feature/user-authentication

# 完成功能开发
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

# 开始发布准备
git flow release start 1.0.0

# 完成发布准备
git flow release finish 1.0.0

# 开始热修复
git flow hotfix start security-fix

# 完成热修复
git flow hotfix finish security-fix

Git Flow适用场景

• 有计划发布周期的项目
• 需要同时维护多个版本的软件
• 较大规模的团队和项目
• 需要严格控制代码质量和发布过程的场景

GitHub Flow工作流

GitHub Flow是由GitHub团队开发的一种简化工作流，专注于持续部署和频繁发布。相比Git Flow，它更加轻量级，适合Web应用和持续集成环境。

核心原则

1. master分支始终可部署：主分支代码应随时可以部署到生产环境
2. 从master创建功能分支：所有新工作都在基于最新master的分支中进行
3. 定期推送到远程分支：频繁提交和推送，方便早期反馈
4. 创建Pull Request：准备合并时创建PR，方便代码审查和讨论
5. 通过测试后合并：通过自动化测试和代码审查后合并到master
6. 合并后立即部署：合并到master后立即部署到生产环境

图3: GitHub Flow工作流程图

GitHub Flow工作流程

git checkout master
git pull origin master
git checkout -b feature-login-page

git add .
git commit -m "Add login form and validation"
git push -u origin feature-login-page

# 某些CI/CD系统会自动部署PR分支
# 或手动部署
git push heroku feature-login-page:master

git checkout master
git merge feature-login-page
git push origin master

GitHub Flow适用场景

• 持续部署的Web应用或服务
• 小型团队或开源项目
• 需要快速迭代和发布的产品
• 具有良好自动化测试覆盖的项目

GitLab Flow工作流

GitLab Flow是对GitHub Flow的扩展，增加了环境分支和版本分支的概念，旨在解决持续部署和版本管理之间的平衡。

核心理念

GitLab Flow采用"上游优先"原则，即更改总是从上游分支（如master）流向下游分支（如生产环境分支），确保代码按环境顺序部署和测试。

GitLab Flow的两种主要变体

1. 环境分支模式

适用于需要在不同环境中逐步部署的项目，维护多个长期环境分支：

• master：开发分支，包含最新代码
• pre-production：预生产环境分支
• production：生产环境分支

代码先合并到master，然后根据需要合并到下游环境分支。

图4: GitLab Flow环境分支模式

2. 版本分支模式

适用于需要维护多个版本的软件产品，从master创建版本分支：

• master：主开发分支
• 1-0-stable：1.0版本的维护分支
• 1-1-stable：1.1版本的维护分支

版本分支只接收bug修复和安全补丁，不接收新功能。

图5: GitLab Flow版本分支模式

GitLab Flow工作流程

git checkout master
git pull origin master
git checkout -b feature/user-profiles

git add .
git commit -m "Add user profile page and settings"
git push origin feature/user-profiles

# 部署到预生产环境
git checkout pre-production
git merge master
git push origin pre-production

# 测试通过后部署到生产环境
git checkout production
git merge pre-production
git push origin production

# 从master创建版本分支
git checkout master
git checkout -b 2-0-stable
git push origin 2-0-stable

# 创建修复分支
git checkout 2-0-stable
git checkout -b hotfix/login-issue

# 修复并提交
git add .
git commit -m "Fix login issue in v2.0"
git push origin hotfix/login-issue

# 创建MR到2-0-stable分支

# 同时创建MR到master分支（上游优先原则）

GitLab Flow适用场景

• 需要多环境部署流程的项目
• 需要同时维护多个版本的软件
• 混合了持续部署和计划发布的项目
• 需要为客户维护定制版本的产品

主干开发（Trunk-Based Development）

主干开发是一种源代码管理实践，开发者频繁地将小改动合并到主分支（通常是master或main），避免长期存在的功能分支。它是持续集成（CI）的关键实践，也是DevOps文化的重要组成部分。

核心原则

• 单一主干：所有团队成员共同在一个主分支上工作
• 短生命周期分支：功能分支存在时间短（通常不超过1-2天）
• 小批量提交：频繁提交小的、自包含的更改
• 持续集成：每次提交后自动构建和测试
• 功能开关：使用代码中的开关来控制未完成功能的可见性

图6: 主干开发工作流示意图

主干开发工作流程

git checkout main
git pull origin main

git checkout -b short-lived-feature
# 完成工作后迅速合并回主干

git checkout main
git merge short-lived-feature
git push origin main

// 代码中使用功能开关控制新功能的可见性
if (featureFlags.isEnabled('new-user-dashboard')) {
    // 新功能代码
} else {
    // 旧功能代码
}

git checkout main
git checkout -b release-2.0
# 只进行小修复和准备工作，不添加新功能

主干开发的优势

• 降低合并冲突风险：频繁集成减少大型合并的复杂性
• 更快的反馈循环：问题更早被发现和修复
• 简化版本控制：减少分支管理的复杂性
• 支持持续部署：主干随时可以部署
• 提高团队协作：所有人都在同一个代码基础上工作

主干开发适用场景

• DevOps和持续部署环境
• 具有强大自动化测试覆盖的项目
• 成熟的敏捷开发团队
• SaaS和网络服务类应用