Git 进阶实战篇：从分支协作到高阶排错指南#

1.1 分支的本质#

很多新手觉得分支是一个很“重”的概念，认为创建分支就是复制了一份完整的代码目录。事实上，Git 的分支极其轻量。

分支的底层逻辑

在 Git 中，分支的本质只是一个指向某次提交快照的可变指针。 当你创建一个新分支时，Git 只是创建了一个新的指针，并不会复制任何文件，因此创建和切换分支的操作几乎是瞬间完成的。

1.2 为什么需要分支#

• 功能隔离：你在开发新功能 A，同事在开发功能 B，两人在各自的分支上互不干扰。
• 并行开发：新功能开发进行到一半时，线上突然爆出一个严重 Bug。你可以立刻切回主分支，拉取一个紧急修复分支，修完后再切回原分支继续开发。
• 安全沙箱：在分支上即使代码写得再烂、哪怕系统崩溃，也不会影响主分支的稳定性。

1.3 从「一条线提交」到「多分支协作」的思维转变#

掌握分支意味着你需要从“单机单机存档”的思维，转变为“平行宇宙合并”的思维。在不同的分支中穿梭，并在适当的时机将它们交织在一起，这就是 Git 协作的艺术。

2.1 基础分支命令#

日常开发中，我们最常使用的就是分支的增删改查。

1
# 查看本地分支（当前分支前会有 * 号）
2
git branch
3

4
# 查看所有分支（包括远程分支）
5
git branch -a
6

7
# 创建新分支
8
git branch feature-login
9

10
# 切换分支（老版本使用 git checkout）
11
git switch feature-login
12

13
# 创建并一键切换到新分支（最高频命令）
14
git switch -c feature-pay
15

16
# 删除分支（必须先切换到其他分支才能删除）
17
git branch -d feature-login
18

19
# 强制删除分支（如果该分支的代码还没被合并过）
20
git branch -D feature-login

checkout 与 switch 的区别

老版本的 Git 中，git checkout 既可以用来切换分支，又可以用来撤销文件修改，职责过于混乱。从 Git 2.23 版本开始，官方引入了专门用于切换分支的 git switch 和专门用于恢复文件的 git restore，推荐大家使用新命令。

2.2 分支合并：git merge#

当你完成了 feature-pay 分支的开发，需要把它合并到 main 主分支时：

1
# 1. 首先切换回目标分支（接收代码的分支）
2
git switch main
3

4
# 2. 将指定分支合并到当前分支
5
git merge feature-pay

合并通常分为两种情况：

1. 快进合并（Fast-forward）：如果 main 分支在创建 feature-pay 之后没有任何新的提交，Git 只需要把 main 指针直接向前移动即可。
2. 三方合并（Three-way merge）：如果 main 分支也有了新的独立提交，Git 会找到两个分支的共同祖先，并将两边的修改整合在一起，自动创建一个新的合并提交（Merge Commit）。

2.3 合并冲突处理#

当两个分支修改了同一个文件的同一行代码时，Git 无法自动决定保留谁的代码，就会产生冲突（Conflict）。

1
<<<<<<< HEAD
2
（当前 main 分支的代码）
3
console.log('使用支付宝支付');
4
=======
5
（feature-pay 分支的代码）
6
console.log('使用微信支付');
7
>>>>>>> feature-pay

1
git add .
2
git commit -m "fix: 解决支付模块的代码冲突"

2.4 变基 git rebase#

除了 merge，Git 还提供了另一种整合代码的方式：变基（Rebase）。

1
# 在 feature 分支上执行，将 base 变为 main 的最新提交
2
git rebase main

3.1 本地分支与远程分支的关系#

当你执行 git clone 时，Git 不仅下载了代码，还在本地创建了远程分支的只读书签（例如 origin/main）。你本地的 main 分支实际上是在“跟踪”这个远程书签。

3.2 fetch 与 pull 的本质区别#

• git fetch：只去远程仓库把最新的提交记录和书签（origin/main）拉取下来，但不会自动合并到你的本地代码中。这给了你查看别人改了什么的机会。
• git pull：相当于 git fetch 加上 git merge。直接拉取并立即尝试合并。

为什么推荐先 fetch？

在不确定远程是否有大规模破坏性更新时，先 git fetch，然后通过 git log origin/main 确认改动，再决定是否执行 git merge origin/main，这是一种更加安全稳妥的做法。

3.3 远程分支操作#

1
# 推送本地新分支到远程，并建立跟踪关系
2
git push -u origin feature-new
3

4
# 删除远程分支
5
git push origin --delete feature-old
6

7
# 查看本地分支与远程分支的跟踪关系
8
git branch -vv

4.1 Git Flow：最经典的重型工作流#

最严谨、分支角色最明确的协作流。适用于版本发布周期固定、客户端软件开发等中大型项目。

五大核心分支：

• master：生产环境的稳定分支，只能通过打标签（Tag）发布，不直接提交。
• develop：日常开发的集成主分支。
• feature/*：功能分支，从 develop 拉取，开发完合并回 develop。
• release/*：发布准备分支，用于测试和修复发布前的 Bug。
• hotfix/*：紧急修复分支，从 master 拉取，修完后同时合并回 master 和 develop。

4.2 GitHub Flow：轻量级协作流#

极致简单，适用于持续交付、快速迭代的互联网项目。

核心逻辑：

1. main 分支始终保持可发布状态。
2. 任何新功能或 Bug 修复，都从 main 拉取新分支。
3. 开发完成后，向 main 提交 Pull Request (PR)。
4. 团队成员进行 Code Review，确认无误后合并到 main 并立即部署。

4.3 GitLab Flow：带环境分支的工作流#

在 GitHub Flow 的基础上，增加了环境分支机制。适用于有测试环境（Test）、预发环境（Pre-production）、生产环境（Production）隔离的项目。代码只能按照环境的顺序依次向上游合并（下游环境 -> 上游环境）。

5.1 储藏工作区 git stash#

场景：代码写了一半，突然要切分支修 Bug，但现在不想提交这半拉子代码。

1
# 把当前暂存区和工作区的改动藏起来
2
git stash
3

4
# 切分支去干别的...修完 Bug 切回来
5

6
# 把藏起来的代码恢复，并从储藏列表中删除
7
git stash pop
8

9
# 查看当前藏了多少次
10
git stash list

5.2 标签管理 git tag#

标签通常用于标记发布的版本号（如 v1.0.0），它就像是打在某个特定提交上的“不可移动的分支”。

1
# 打一个轻量标签
2
git tag v1.0.0
3

4
# 打一个带注释的附注标签（推荐）
5
git tag -a v2.0.0 -m "发布 2.0 大版本，重构支付链路"
6

7
# 推送标签到远程仓库（默认 push 不会推送标签）
8
git push origin v2.0.0
9
# 推送所有标签
10
git push origin --tags

5.3 提交历史修改#

1
# 刚才的提交漏了一个文件，或者备注写错了？
2
git add 漏掉的文件.txt
3
git commit --amend -m "新的正确提交信息"
4

5
# 想要把某几个特定的提交整合在一起？（交互式变基）
6
git rebase -i HEAD~3

5.4 挑选提交 git cherry-pick#

场景：你在测试分支修了一个紧急 Bug，现在只想把这一个 Bug 修复的提交合并到生产分支，而不想合并整个测试分支。

1
# 拿到那个提交的 Hash 值（如 a1b2c3d）
2
git cherry-pick a1b2c3d

6.1 提交错了分支怎么办？#

场景：本该在 feature 分支开发，结果把代码提交到了 main 分支。

解决步骤：

1
# 1. 记录下刚才误提交的 Hash 值
2
git log -1
3

4
# 2. 把 main 分支的状态回退到上一个版本
5
git reset --hard HEAD~1
6

7
# 3. 切换到正确的分支
8
git switch feature
9

10
# 4. 把刚才的提交“挑”过来
11
git cherry-pick <刚才的Hash值>

6.2 撤回提交的三种模式 git reset#

当你需要时光倒流时，git reset 是最强大的武器。

• git reset --soft HEAD~1：温柔模式。只撤销 commit 动作，代码原封不动保留在暂存区。
• git reset --mixed HEAD~1（默认）：中庸模式。撤销 commit 和 add，代码退回到工作区（变成未暂存状态）。
• git reset --hard HEAD~1：毁灭模式。彻底抹除最近一次提交，连带改动的代码一起物理删除。（极度危险，慎用！）

6.3 误删分支 / 误硬重置如何救回？（终极后悔药）#

如果你不小心执行了 git reset --hard，或者强制删除了未合并的分支，其实代码还在 Git 底层数据库中！

1
# 查看你在这个仓库里执行过的每一次 HEAD 移动记录
2
git reflog
3

4
# 找到你想要恢复的那个动作前的 Hash 值（如 c4f9d2a）
5
git reset --hard c4f9d2a

只要你不主动清理 Git 垃圾，近期的误操作几乎都能用 reflog 找回来。

6.4 敏感文件 / 大文件已提交，如何彻底清除？#

如果不小心把包含密码的 .env 提交了，普通的 git rm 删除再提交是没有用的，别人依然可以从历史记录里翻出来。 必须使用第三方工具如 BFG Repo-Cleaner，或者使用最新的 git filter-repo 彻底重写所有历史记录。

6.5 .git 目录损坏的应急处理#

如果不幸遭遇断电导致 .git 损坏，报各种 fatal: loose object is corrupt 错误：

1. 立即备份整个项目文件夹！
2. 尝试运行 git fsck --full 检查损坏。
3. 如果只是 HEAD 文件损坏，尝试手动编辑 .git/HEAD 文件修复指向。
4. 终极自救：重新 git clone 一份干净的代码，把你工作区修改的代码手动覆盖过去。

7.1 Commit Message 规范#

推荐采用 Conventional Commits (约定式提交) 规范：

• feat: 新增功能
• fix: 修复 Bug
• docs: 文档更新
• style: 代码格式修改（不影响逻辑）
• refactor: 代码重构
• test: 测试用例补充

7.2 协作好习惯#

• 小步提交：把大任务拆分成多个逻辑独立的小 commit，千万不要积攒一周的代码一次性提交。
• 避免巨型 PR：每次 Pull Request 的改动最好控制在 500 行以内，否则 Code Review 的同事只会直接点“Approve”而不看内容。
• 推送前先拉取：养成 git pull --rebase 的习惯，保持提交树的整洁。

7.3 可视化工具推荐#

命令行虽然强大，但看分支拓扑图时可视化工具更直观：

• VS Code 内置 Git & GitLens 插件：日常开发最轻量高效的搭配。
• SourceTree：Atlassian 出品的免费神器，分支图非常清晰。
• GitKraken：颜值极高的跨平台 Git 客户端，适合重度分支操作者。

进阶命令速查表#

Git 的学习曲线是陡峭的，从单分支到多分支，从合并冲突到排错自救，每一个知识点都需要在实践中反复踩坑才能真正掌握。 建议的学习路径：先在个人的 Demo 项目中大胆尝试 merge、rebase 和 reset，熟练后再去 GitHub 参与开源项目的 PR 流程，最后将其规范化地落地到公司的团队协作中。

记住，命令只是工具，理解 Git 的“快照指针”底层思想，才是你不再害怕报错的核心。祝你再也不会被代码冲突搞得焦头烂额！