Git与GitHub协作指南第3篇：分支策略 - 高效工作流

Branch Strategy - Efficient Workflow for Team Collaboration

2026-01-22 IT/技术

前言：为什么分支策略很重要

在前面的文章中，我们学习了Git的基本概念和GitHub仓库创建。这次我们将深入探讨团队项目中最重要的要素之一——分支策略。

一个人开发时没什么问题的事情，随着团队成员增加开始变得复杂。"谁在开发什么功能？"、"这段代码为什么突然变了？"、"部署前需要紧急修复bug怎么办？"这样的情况频繁发生。正是为了解决这些问题，我们需要分支策略。

设计良好的分支策略在最小化团队成员之间的冲突、系统化部署流程、维护代码质量方面发挥着关键作用。现在让我们从分支的基本概念开始，逐一了解实际工作中广泛使用的策略。

1. 什么是分支

1.1 分支的概念

分支(Branch)顾名思义就是"树枝"的意思。就像从树干上伸出许多树枝一样，可以从一个代码库创建多个独立的工作流。

使用分支可以在不影响主代码的情况下开发新功能或修复bug。工作完成后，再合并(merge)回主代码，这就是协作的方式。

分支是指向特定提交的指针。创建新分支意味着在当前位置创建一个新指针，之后每个分支上的提交只会移动该分支的指针。

1.2 为什么需要分支

想象一下没有分支的工作。如果所有团队成员同时在一个代码上工作会发生什么？

频繁的代码冲突：多人修改同一个文件时经常发生冲突。
部署不完整的代码：正在开发的功能可能被意外部署。
回滚困难：出现问题时很难只回滚特定功能。
无法并行工作：一个人必须等另一个人完成工作。

使用分支可以自然地解决这些问题。每个人在独立的空间工作，只合并完成的部分即可。

2. 分支基本命令

2.1 创建和查看分支

让我们来看看最基本的分支相关命令。

# 查看当前分支列表
git branch

# 查看包括远程分支在内的所有分支
git branch -a

# 创建新分支（从当前分支分叉）
git branch feature/login

# 创建分支并同时切换
git checkout -b feature/login

# 或者使用最新方式
git switch -c feature/login

2.2 切换分支：checkout vs switch

从Git 2.23版本开始引入了switch命令。原来的checkout除了切换分支外还负责文件恢复等多种功能，现在将其分离以提高直观性。

# 旧方式（仍可使用）
git checkout feature/login

# 新方式（推荐）
git switch feature/login

# 返回上一个分支
git switch -

个人更推荐使用switch命令。用途明确，可以防止意外覆盖文件。

2.3 分支合并（Merge）

将完成工作的分支合并到其他分支称为合并(merge)。

# 切换到main分支
git switch main

# 将feature/login分支合并到main
git merge feature/login

# 合并完成后删除分支（可选）
git branch -d feature/login

2.4 删除分支

# 删除已合并的分支
git branch -d feature/login

# 强制删除未合并的分支（需谨慎）
git branch -D feature/experimental

# 删除远程分支
git push origin --delete feature/login

3. Git Flow策略

3.1 什么是Git Flow

Git Flow是Vincent Driessen于2010年提出的分支策略，广泛用于大型项目。它有明确的规则和结构，使所有团队成员能够以一致的方式工作。

3.2 Git Flow的分支类型

主分支（永久保持）

main（或master）：只存在部署到生产环境的代码。所有提交都带有版本标签。
develop：为下一个发布进行开发的分支。feature分支合并到这里。

辅助分支（需要时创建后删除）

feature/*：用于新功能开发。从develop分叉，合并到develop。
release/*：用于发布准备。从develop分叉，合并到main和develop两边。
hotfix/*：用于紧急bug修复。从main分叉，合并到main和develop两边。

3.3 Git Flow实际使用示例

# 1. 开始新功能开发
git switch develop
git switch -c feature/user-authentication

# 2. 功能开发完成后合并到develop
git switch develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

# 3. 准备发布
git switch -c release/1.0.0 develop

# 4. 在release分支上完成最后修改后合并到main
git switch main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Version 1.0.0"

# 5. 也合并到develop
git switch develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

# 6. 紧急bug修复（hotfix）
git switch main
git switch -c hotfix/critical-bug

# 7. 修复后合并到main和develop两边
git switch main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix: critical bug"
git switch develop
git merge --no-ff hotfix/critical-bug
git branch -d hotfix/critical-bug

3.4 Git Flow的优缺点

优点

明确的规则使大型团队也能保持一致性
系统化的发布版本管理
生产代码和开发代码明确分离
为紧急修复提供明确的流程

缺点

分支多可能变得复杂
不适合频繁部署（CI/CD）
对于小型项目是过度的开销

4. GitHub Flow策略

4.1 什么是GitHub Flow

GitHub Flow是降低了Git Flow复杂性的简单高效策略。由GitHub提出，针对CI/CD环境进行了优化。

4.2 GitHub Flow的规则

main分支始终保持可部署状态
新工作从main创建分支开始
分支名称要有描述性（例如：feature/add-login、fix/header-bug）
工作中经常push到远程进行备份
准备好后创建Pull Request
代码审查后合并到main
合并后立即部署

4.3 GitHub Flow实际使用示例

# 1. 从main创建新分支
git switch main
git pull origin main
git switch -c feature/shopping-cart

# 2. 工作时经常提交
git add .
git commit -m "Add cart item component"
git push origin feature/shopping-cart

# 3. 继续工作
git add .
git commit -m "Implement cart total calculation"
git push origin feature/shopping-cart

# 4. 在GitHub上创建Pull Request
# （使用网页界面或gh CLI）

# 5. 审查完成后合并到main（通常在GitHub网页上进行）

# 6. 清理本地
git switch main
git pull origin main
git branch -d feature/shopping-cart

4.4 GitHub Flow的优缺点

优点

非常简单易懂
适合持续部署（CD）
适合小型团队
快速的反馈循环

缺点

发布版本管理不够明确
需要同时维护多个版本时不太适合

5. Trunk Based Development

5.1 什么是Trunk Based Development

Trunk Based Development(TBD)是所有开发者直接在一个分支（trunk或main）上工作的方式。Google、Facebook等大型科技公司使用这种方式。

5.2 核心原则

短命的分支：分支在一天内合并
小单位的提交：大功能也分成小块频繁提交
使用Feature Flag：未完成的功能用标志隐藏
强大的测试自动化：每次提交都运行自动测试

5.3 Feature Flag示例

// 用标志控制未完成的功能
const FEATURES = {
  newCheckout: false,  // 仍在开发中
  darkMode: true       // 已发布
};

function renderCheckout() {
  if (FEATURES.newCheckout) {
    return <NewCheckout />;
  }
  return <OldCheckout />;
}

5.4 TBD的优缺点

优点

最小化合并冲突
针对持续集成（CI）优化
频繁的代码集成，早期发现问题

缺点

需要高水平的测试自动化
Feature Flag管理复杂度增加
需要团队成员具备高能力和纪律性

6. 分支策略选择指南

6.1 按项目规模推荐

项目类型	推荐策略	原因
1-2人小型项目	GitHub Flow	简单快速
初创公司（5-10人）	GitHub Flow	适合快速迭代和部署
中型团队（10-30人）	Git Flow或变体	需要系统化的发布管理
大型组织	Git Flow或TBD	需要明确规则或强大自动化
开源项目	GitHub Flow	适合处理外部贡献者的PR

6.2 按部署周期推荐

每日或随时部署：GitHub Flow、TBD
每周或Sprint单位部署：GitHub Flow、Git Flow简化版
每月或每季度发布：Git Flow

7. 解决合并冲突

7.1 为什么会发生合并冲突

当两个分支对同一个文件的同一部分进行了不同的修改时，Git无法自行判断应该保留哪个更改。这时就会发生冲突(conflict)，需要开发者手动解决。

7.2 解决冲突的过程

# 尝试合并
git merge feature/login
# CONFLICT (content): Merge conflict in src/App.js

# 查看冲突文件
git status

# 打开冲突文件会看到以下内容
# <<<<<<< HEAD
# const title = "Welcome";
# =======
# const title = "Hello World";
# >>>>>>> feature/login

理解冲突标记就容易解决了：

<<<<<<< HEAD：当前分支（合并目标）的内容
=======：分隔线
>>>>>>> feature/login：要合并的分支的内容

7.3 解决冲突并完成

# 1. 直接编辑文件写入最终代码
# 删除所有冲突标记，只保留想要的代码

# 2. 暂存已解决的文件
git add src/App.js

# 3. 创建合并提交
git commit -m "Merge feature/login: resolve conflict in App.js"

# 或者取消合并
git merge --abort

7.4 预防冲突的技巧

经常pull保持最新状态
保持分支生命周期短
与其用大文件不如分成多个小文件
与团队成员协调工作区域

8. Rebase vs Merge

8.1 Merge的特点

Merge保留两个分支的历史并合并。

git switch main
git merge feature/login

优点

历史准确保留
易于理解工作上下文
安全且容易回滚

缺点

历史可能变得复杂
可能产生很多不必要的合并提交

8.2 Rebase的特点

Rebase将提交"重新放置"到另一个分支上。历史看起来就像一开始就在那个分支上工作一样。

# 在feature分支上重新放置到main的最新内容之上
git switch feature/login
git rebase main

# 在main上进行fast-forward合并
git switch main
git merge feature/login

优点

干净的线性历史
没有不必要的合并提交
代码审查时更容易追踪变更

缺点

历史会被修改，需要注意
对已push的分支慎用
可能需要多次解决冲突

8.3 什么时候用什么

情况	推荐
整理仅在本地工作的分支	Rebase
已push到远程的分支	Merge
共享分支（main、develop）	Merge
更新feature分支	Rebase（push前）
有团队规则时	遵循团队规则

黄金法则："不要rebase已公开(push)的历史。" 如果rebase别人正在基于的提交，会造成很大的混乱。

总结：分支策略是团队文化

到目前为止，我们学习了从分支的基本概念到各种分支策略，以及解决冲突的方法。很难说哪种策略是"正确答案"。重要的是选择适合团队情况的策略，让所有团队成员遵循相同的规则。

一开始从简单的GitHub Flow开始，随着项目的发展根据需要添加规则也是一个好方法。分支策略不是定了就结束，而是应该随着团队和项目的成长一起进化。

在下一篇文章中，我们将学习Pull Request和代码审查。PR和代码审查是实际运营分支策略的必要要素，请一定要继续阅读。

返回列表