Git 工作流指南:团队分支策略

· 12分钟阅读

📑 目录

Git 是无可争议的版本控制之王,被全球超过 95% 的开发团队使用。但了解 Git 命令只是成功的一半——真正的挑战是选择并始终遵循适合团队的分支策略。

良好的 Git 工作流可以防止合并冲突、支持并行开发、维护代码质量并使发布可预测。没有工作流,你就会陷入混乱、构建失败和开发人员沮丧的境地。

为什么 Git 工作流很重要

想象一下:周五下午,你的团队刚刚将一个关键的 bug 修复推送到生产环境。但等等——其他人同时将一个未经测试的功能直接合并到了 main。现在生产环境崩溃了,没人知道是哪个提交导致的问题,你的周末计划泡汤了。

这种情况在没有定义 Git 工作流的团队中经常发生。以下是会出现的问题:

定义良好的 Git 工作流为何时分支、如何合并以及谁批准更改建立了明确的规则。它在团队中创建了关于代码如何从开发到生产的共同理解。

专业提示: 最好的工作流是团队实际遵循的工作流。从简单开始,只在需要时增加复杂性。一个每个人都理解的基本工作流胜过一个没人遵循的复杂工作流。

特性分支工作流

特性分支工作流是最广泛采用的 Git 工作流,这是有充分理由的。它简单、灵活,适用于任何规模的团队。核心原则:每个新功能或 bug 修复都从 main 创建自己的分支。

开发人员在他们的特性分支上独立工作,然后在代码审查后创建拉取请求以合并回 main。这使 main 始终保持稳定和可部署状态。

工作原理

以下是添加新功能的典型流程:

# 从 main 开始并获取最新更改
git checkout main
git pull origin main

# 创建新的特性分支
git checkout -b feature/user-authentication

# 进行更改并提交
git add .
git commit -m "feat: add login form validation"

# 推送到远程
git push origin feature/user-authentication

# 在 GitHub/GitLab 上创建 PR 进行代码审查
# 批准后,合并到 main
# 删除特性分支

分支命名约定

一致的命名使理解每个分支的作用变得容易。以下是常见的前缀:

何时使用特性分支工作流

此工作流在以下情况下表现出色:

潜在陷阱

注意这些常见问题:

快速提示: 保持特性分支短期存在(理想情况下少于 3 天)。如果功能需要更长时间,将其分解为可以在功能标志后逐步合并的较小部分。

GitFlow 工作流

GitFlow 是为具有计划发布的项目设计的更结构化的工作流。它使用多个长期存在的分支来管理开发和发布准备的不同阶段。

由 Vincent Driessen 于 2010 年创建,GitFlow 在定期发布软件(每月、每季度等)的团队中变得流行。它在开发、发布准备和生产代码之间提供了清晰的分离。

分支结构

GitFlow 使用五种类型的分支:

完整的 GitFlow 周期

以下是代码如何流经 GitFlow:

# 初始化 GitFlow(一次性设置)
git flow init

# 开始新功能
git flow feature start user-profile
# 处理功能...
git flow feature finish user-profile
# 自动合并到 develop

# 当 develop 准备好时开始发布
git flow release start 1.2.0
# 仅进行 bug 修复和版本更新
git flow release finish 1.2.0
# 合并到 main 和 develop,创建标签

# 紧急热修复
git flow hotfix start security-patch
# 修复问题...
git flow hotfix finish security-patch
# 合并到 main 和 develop

何时 GitFlow 有意义

GitFlow 适用于:

为什么 GitFlow 失宠

许多现代团队已经放弃 GitFlow,因为:

即使是 GitFlow 的创建者 Vincent Driessen,现在也建议大多数持续部署的 Web 应用使用更简单的工作流。

主干开发

主干开发(TBD)是 Google、Facebook 和 Netflix 等高性能工程团队使用的工作流。它与 GitFlow 相反——开发人员直接提交到 main("主干")或使用非常短期的特性分支,而不是长期存在的分支。

关键原则:频繁集成代码(每天多次)以避免大型合并的痛苦。

主干开发的工作原理

TBD 有两种变体:

直接提交到 main:

# 拉取最新更改
git pull origin main

# 进行小的更改
git add .
git commit -m "feat: add email validation"

# 直接推送到 main
git push origin main

短期特性分支(推荐给大多数团队):

# 为小更改创建分支
git checkout -b add-email-validation

# 进行更改并提交
git add .
git commit -m "feat: add email validation"

# 推送并创建 PR
git push origin add-email-validation

# 在 24 小时内合并,删除分支

功能标志的作用

主干开发严重依赖功能标志(也称为功能切换)来向用户隐藏不完整的功能。这允许你在功能准备好投入生产之前将代码合并到 main。

// 功能标志示例
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckoutFlow />;
}
return <OldCheckoutFlow />;

使用功能标志,你可以:

成功实施 TBD 的要求

主干开发需要强大的工程实践:

主干开发的好处

如果做得好,TBD 提供显著的优势:

专业提示: 如果你的团队刚接触 CI/CD,不要直接跳到主干开发。首先建立你的测试基础设施和部署自动化,然后逐步缩短你的特性分支生命周期。

为团队选择合适的工作流

没有一刀切的答案。正确的工作流取决于你的团队规模、发布节奏和工程成熟度。以下是如何决定:

工作流 最适合 团队规模 发布节奏
特性分支 Web 应用、SaaS 产品、大多数现代团队 任何规模 持续或每周
GitFlow 桌面/移动应用、版本化发布 中型到大型 每月或每季度
主干开发 具有强大 CI/CD 的高速团队 任何规模(需要纪律) 每天多次

决策框架

问自己这些问题:

1. 你多久部署一次到生产环境?

2. 你的 CI/CD 管道有多成熟?