04. Git 分支管理：5 步彻底搞懂 branch 与 merge
「Git」系列已发布： 00. 改崩代码不敢回退？Git 版本控制 3 分钟救你狗命 ｜ 01. Git 装完不会配？Windows/macOS/Linux 三端配置一次到位 ｜ 02. Git 配置总踩坑？全局/仓库/SSH 密钥一次搞懂 ｜ 03. add/commit/push 别再死记：Git 工作流核心概念实操 ｜ 04. Git 分支管理：5 步彻底搞懂 branch 与 merge（本文） ｜ 05. clone/fetch/pull/push 分不清？Git 远程协作实战
分支是 Git 最强大的能力，也是新人最怕的。5 步从创建、切换、合并到冲突处理，彻底搞懂 branch 与 merge，团队协作不再乱。
建议先看完前 03 篇。下面所有操作都在已初始化的 Git 仓库里执行，准备一个测试仓库跟着练效果最好。
一、分支到底是什么
在进操作之前，先搞清楚 Git 分支在底层怎么实现的——这决定了为什么 Git 的分支操作这么快、这么灵活。
说穿了，Git 分支就是一个指向某个提交对象的可变指针。创建分支就是在.git/refs/heads/下写入一个 41 字节的文件（40 字节 SHA-1 + 换行符），记录这个分支当前指向的 commit ID。
# 看看分支指针里实际存了什么
cat .git/refs/heads/main
# 输出：a3f2b1c...（40 位十六进制字符串）
# 这就是为什么 Git 分支操作几乎是瞬时
# 创建分支 = 写一个 41 字节的文件
还有一个特殊指针叫
HEAD，它指向当前检出的分支：
cat .git/HEAD
# 输出：ref: refs/heads/main（表示你在 main 分支上）
# 当 HEAD 直接指向某个提交而不是分支时，就是"分离头指针"（detached HEAD）
# 输出：a3f2b1c...（纯哈希，没有 ref: 前缀）
1.1 分支基础操作
1.1.1 创建与切换
# 创建分支（不切过去）
git branch feature-login
# 创建并切换
git checkout -b feature-payment
# 新版写法（语义更明确）
git switch -c feature-notification
# 列出所有本地分支
git branch
# 列出包括远程的所有分支
git branch -a
# 看每个分支的最新提交
git branch -v
# 已合并到当前分支的
git branch --merged
# 还没合并的
git branch --no-merged
1.1.2 切换
# 切到已有分支
git checkout main
# 新版
git switch main
# 切回上一个分支
git switch -
# 切到特定的远程分支
git checkout -b feature-login origin/feature-login
1.1.3 删除
# 删已合并的（安全）
git branch -d feature-login
# 强制删（即使没合并）
git branch -D feature-abandoned
# 删远程分支
git push origin --delete feature-login
# 清理本地已经不存在的远程跟踪引用
git remote prune origin
1.2 合并分支
合并是分支管理的核心。Git 提供了两种整合方式：merge和rebase。
1.2.1 git merge
merge把两个分支的最新提交和它们的共同祖先做三方合并，生成一个新的"合并提交"。
# 切到目标分支（一般是 main）
git checkout main
# 把 feature 分支合进来
git merge feature-login
合并的三种情形：
快进合并（Fast-forward）：目标分支在分叉后没有任何新提交时，Git 直接把指针前移。不会产生合并提交。
gitGraph commit id: "D" commit id: "E" branch feature commit id: "A" commit id: "B" commit id: "C" checkout main merge feature
合并前：main 在 E，feature 在 C。合并后（快进）：main 指针直接移到 C。
# 强制生成合并提交（即使可以快进）
git merge --no-ff feature-login
三方合并：两个分支在分叉后都有新提交，Git 基于共同祖先做三方合并，自动生成合并提交。
gitGraph commit id: "D" commit id: "E" branch feature commit id: "A" commit id: "B" commit id: "C" checkout main commit id: "F" commit id: "G" merge feature id: "H"
合并前：main 在 G，feature 在 C，分叉后双方都有新提交。合并后：Git 基于共同祖先 E 做三方合并，生成合并提交 H。
1.2.2 解决冲突
两个分支改了同一文件的同一区域时，Git 不知道该听谁的，于是产生冲突。
冲突标记格式：
<<<<<<< HEAD
当前分支（main）的内容
要合进来的分支（feature）的内容
>>>>>>> feature-login
解决步骤：
# 1. 合并遇到冲突
git merge feature-login
# Auto-merging src/config.py
# CONFLICT (content): Merge conflict in src/config.py
# 2. 看哪些文件冲突了
git status
# 3. 手动编辑冲突文件，删掉标记，保留正确内容
# 4. 标记已解决
git add src/config.py
# 5. 完成合并
git commit -m "合并 feature-login 分支，解决 config.py 冲突"
# 想放弃合并？
git merge --abort
1.2.3 合并策略
# 默认策略（ort，Git 2.34+）
git merge feature-login
# 把 feature 的所有提交压缩成一个再合并（保持 main 历史干净）
git merge --squash feature-login
git commit -m "合并 feature-login 分支的所有修改"
# 冲突时优先用当前分支内容
git merge -X ours feature-login
# 冲突时优先用对方的内容
git merge -X theirs feature-login
1.3 变基（rebase）
rebase是另一种整合方式。和merge不一样，rebase把当前分支的提交"搬"到目标分支顶端，产生一条线性的提交历史。
# 切到 feature 分支
git checkout feature-login
# 把 feature-login 的提交变基到 main 之上
git rebase main
变基过程：
gitGraph commit id: "D" commit id: "E" branch feature commit id: "A" commit id: "B" commit id: "C" checkout main commit id: "F" commit id: "G"
变基前：feature 分支在 A-B-C，main 在 D-E-F-G。
gitGraph commit id: "D" commit id: "E" commit id: "F" commit id: "G" branch feature commit id: "A'" commit id: "B'" commit id: "C'"
变基后：feature 的 A’、B’、C’ 被搬到 main 顶端，main 不变。
A’、B’、C’ 是全新的提交，和原来的哈希值不同——变基会重写提交历史。
1.4 交互式变基
git rebase -i是 Git 最强大的历史编辑工具之一：
# 变基最近 3 次提交
git rebase -i HEAD~3
# 变基到 main 并交互编辑
git rebase -i main
可用的操作命令：
| 命令 | 说明 |
|---|---|
pick |
保留该提交（默认） |
reword |
保留但改提交信息 |
edit |
保留但暂停，让你改文件 |
squash |
合并到上一个提交 |
fixup |
同 squash，但丢弃提交信息 |
drop |
删掉这个提交 |
break |
在此暂停，执行任意命令后继续 |
1.5 merge vs rebase：怎么选
| 场景 | 用哪个 | 原因 |
|---|---|---|
| feature 合到 main | merge（–no-ff） | 保留完整合并历史，可追溯 |
| 同步 feature 到最新 main | rebase | 保持 feature 分支历史整洁 |
| 整理本地没推送的提交 | rebase -i | 清理和优化提交历史 |
| 公共分支上的操作 | merge | rebase 改写历史会破坏别人的基准 |
| 个人 feature 分支 | rebase | 历史整洁，方便 code review |
一条铁律：永远不要对已经推到公共仓库的提交做 rebase。
1.6 分支工作流模型
1.6.1 Git Flow
最经典的分支模型，分支角色定义得很严格：
gitGraph commit branch develop checkout develop commit branch feature checkout feature commit commit checkout develop merge feature commit commit branch feature2 checkout feature2 commit commit checkout develop merge feature2 branch release checkout release commit commit commit checkout main merge release checkout develop merge release commit commit commit checkout main merge develop
Git Flow 模型：main（正式发布）、develop（开发主线）、feature（功能开发）、release（发布准备）四类分支协作。
| 分支 | 命名 | 从哪来 | 合到哪 | 生命周期 |
|---|---|---|---|---|
| main | main |
— | — | 永久 |
| develop | develop |
main | main | 永久 |
| feature | feature/* |
develop | develop | 功能完成即删 |
| release | release/* |
develop | main + develop | 发布后删 |
| hotfix | hotfix/* |
main | main + develop | 修复后删 |
1.6.2 GitHub Flow
更简洁，适合持续交付的团队：
gitGraph commit branch feature checkout feature commit commit checkout main merge feature commit commit branch feature2 checkout feature2 commit commit checkout main merge feature2 commit
GitHub Flow：main 始终可部署，功能通过 feature 分支开发，合并后删除 feature 分支。
原则：
main分支始终可部署。- 从
main拉描述性命名的分支开发。 - 定期推送到远端同名分支。
- 需要合并时发起 Pull Request。
- 审查通过后合到
main并立即部署。
1.6.3 Trunk-Based Development
极限持续集成模型，所有开发者直接提交到主干，分支存活时间极短（通常不到一天）。
怎么选：
| 团队规模 | 发布频率 | 推荐模型 |
|---|---|---|
| 小型（<10人） | 持续部署 | GitHub Flow 或 Trunk-Based |
| 中型（10-50人） | 定期发布 | Git Flow 简化版 |
| 大型 / 多版本维护 | 长周期发布 | Git Flow |
| 开源项目 | 按需发布 | GitHub Flow |
1.7 日常分支管理
1.7.1 命名规范
feature/<模块>-<简短描述> # 功能分支
bugfix/<编号>-<简短描述> # 修复分支
hotfix/<版本>-<简短描述> # 热修复
1.7.2 分支保护
在 GitLab/GitHub 上对main和develop设置保护规则：
- 禁止直接 push，必须走 Merge Request / Pull Request。
- 至少 1-2 人 Code Review 通过。
- CI/CD Pipeline 必须跑绿。
- 禁止强制推送（
git push --force）。
1.7.3 定期清理
# 删本地已合并到 main 的分支
git branch --merged main | grep -v "main" | xargs git branch -d
# 删远程已合并的分支
git branch -r --merged main | grep -v "main" | sed 's/origin\///' | xargs -I {} git push origin --delete {}
二、 文章引用
📌 本文首发于微信公众号 【运维知识点滴】——专注运维实战干货，微信搜索“运维知识点滴”或扫下方二维码关注，更新不迷路。
📎 微信原文：04. Git 分支管理：5 步彻底搞懂 branch 与 merge
| 微信公众号【运维知识点滴】 | 微信小程序【A5单据合并&大试卷拆分转A4打印】 |
|---|---|
 |
 |
| 运维实战干货 · 关注追更 | Word 转 PDF · 试卷/发票打印神器 · 免费 |
💡 小程序【A5单据合并&大试卷拆分转A4打印】是干嘛的？ 一个 Word 转 PDF 的打印神器，专治“文档版式和打印机对不上”：
- A3 试卷打不出来？ 学校发的电子版试卷多是 A3，家用打印机只吃 A4——上传 Word 一键转换：可缩到一页 A4（页数不变），也可对半拆成两张 A4（1:1 原大、字更清晰），两种模式自选；
- 版式不乱：真实渲染引擎原样转换、绝不重排内容，转出的 PDF 和原 Word 排版一致，公式/表格/图片不跑版；
- 两张 A5 单据拼一张 A4：出租车票、火车票等报销凭证拼版后，一次打印、整齐粘贴；
- 隐私省心：无需注册，转换结果留存 5 天、最多下载 5 次即自动删除，不留任何历史记录；
- 微信扫码即用，免费、免安装，支持 doc / docx（≤50MB）。
上一篇：03. add/commit/push 别再死记：Git 工作流核心概念实操 ｜ 下一篇：05. clone/fetch/pull/push 分不清？Git 远程协作实战