【Git基础】02——分支：在不破坏主线的情况下做实验

基础篇：【Git 基础】01——代码是怎么被追踪的

​ 之前我们介绍了 git 的基础工作流：add → commit → push。但现实开发很快会遇到一个问题：你想尝试一个新功能，但不确定能不能成功，又不想把 main 分支搞乱。比如，想重构一段代码、想试一个新架构、修一个可能越修越坏的 bug。 这时候，如果所有修改都直接提交到 main，项目很容易进入混乱状态。Git 分支，就是为了解决这个问题而存在的

一、分支是什么

​ 分支可以理解为一条独立的提交时间线。你从 main 上某个节点"分叉"出去，在新分支上自由提交、修改，main 完全不受影响。做好了再合并回去，做坏了直接删掉。

​ 注意，分支不是"复制一份代码"，它只是一个指针，指向某个 commit 节点。创建分支几乎没有开销，这也是 Git 能支持大量并行开发的原因。

二、分支基础操作

2.1 创建并切换分支

git checkout -b feature/login

​ 其中，-b 表示新建分支，feature/login 是分支名。

​ 这条命令等价于：

git branch feature/login    # 创建
git checkout feature/login  # 切换过去

​ 现代 git 更推荐使用 git switch：

git switch -c feature/login   # -c 等同于 -b，create 的意思

​ 分支名的约定：feature/ 前缀表示新功能，fix/ 表示修 bug，release/ 表示发布准备，hotfix/ 紧急修复。Git 不强制，但统一规范会带来两个好处： 分支列表一眼可读 ，CI/CD 自动化更容易配置。

2.2 查看当前在哪个分支

git branch

​ 输出里带 * 的就是当前分支：

* feature/login
  main

​ 本质上，HEAD 指针正在指向这个分支。

2.3 在新分支上正常开放

​ 切到新分支后，工作流和之前完全一样：改代码 → git add → git commit。唯一不同的是，commit 被记录在 feature/login 这条时间线 上，不会影响 main。

2.4 切回 main

git switch main

​ 切回去之后，你会发现工作目录恢复成了 main 的状态，在 feature 分支上做的改动"消失了"。它们没有被删除，只是 git 切换了当前指针，feature 分支的内容还在，切回去就能看到。

​ 其实，这里Git 并不是在“改文件”。Git 在做的是：切换整个项目的历史快照。

2.5 合并分支

​ feature 做好了，合并回 main：

git switch main
git merge feature/login

​ git 会把 feature/login 上的 commit 合并到 main。如果两条分支没有修改同一个地方，合并是自动完成的。

​ 合并完之后，feature 分支就可以删掉了。因为历史已经进入 main，不再需要它。

git branch -d feature/login

三、冲突：两个人改了同一个地方

​ 合并时最常见的麻烦是冲突（conflict），你和别人都修改了同一个文件的同一段代码，git 不知道该保留哪个，就会暂停合并，让你手动决定。

3.1 冲突内容

​ 冲突文件会变成这样：

<<<<<<< HEAD
def greet(name):
    return f"Hello, {name}!"
=======
def greet(name):
    return f"Hi, {name}!"
>>>>>>> feature/login

​ 其中，<<<<<<< HEAD 到 ======= 是你当前分支的版本，而======= 到 >>>>>>> 是要合并进来的版本

3.2 解决方法

​ 直接编辑文件，删掉你不想要的那段和所有 <<<<<<<、=======、>>>>>>> 标记，留下最终想要的代码，然后告诉git你已经解决：

git add 冲突文件名
git commit

​ 冲突解决完毕。

​ 冲突不是 git 的 bug，是正常现象。解决原则很简单：两个版本都看一眼，留你想要的，删掉标记符号，重新提交。冲突是 Git 的安全机制，而不是失败。

四、推送分支到 GitHub

​ 本地分支推到远程：

git push origin feature/login

​ 推上去之后，可以在 GitHub 上开一个 Pull Request（PR），这是"我想把这个分支合并到 main"的申请，团队成员可以在上面 review 代码，CI 也会在这里跑。

​ PR 通过后，点 GitHub 上的 Merge 按钮，就完成了合并。合并完可以在 GitHub 上直接删掉远程分支，本地也同步清理：

git branch -d feature/login           # 删本地分支
git remote prune origin               # 清理本地对已删除远程分支的引用

五、典型的分支工作流

​ 独立项目和团队协作的分支策略不一样。

5.1 独立项目（简单策略）

main        ← 只放稳定、可用的代码
feature/*   ← 每个新功能一个分支，做好合并回 main
fix/*       ← 每个 bug 修复一个分支

5.2 团队协作（常见策略）

main        ← 对应生产环境，只接受 PR 合并，不直接 push
dev         ← 日常开发的集成分支，功能分支合并到这里先验证
feature/*   ← 从 dev 分叉，完成后合并回 dev

​ 不需要在第一个项目就用最复杂的策略，从"main + feature 分支"开始，感受到不够用再升级。

六、总结

​ 记住这几个核心认知，你就真正理解分支了：

• 分支是一条提交历史线

• 分支不是复制代码，而是指针

• 切换分支 = 切换项目快照

• merge 是历史的合流

• 冲突是 Git 请求人工决策

git分支可以让我们安全试错，而软件开发本质上就是持续试错。