Git 分支管理 · 速览

核心原则

永远不在主分支上直接改动，主分支（main/master）永远保证功能完整可用、可部署。所有开发都在分支上进行。

分支基本操作

git branch                        # 查看分支
git branch <name>                 # 创建分支（指针与当前分支相同）
git branch <name> <commit-hash>   # 创建分支并指向指定提交
git switch <name>                 # 切换分支
git switch -                      # 切回上一个分支（两分支间快速来回）
git switch -c <name>              # 创建并切换（快捷方式）
git branch -m <new-name>          # 重命名当前分支
git branch -m <old> <new>         # 重命名指定分支
git branch -d <name>              # 删除分支（安全：未合并会拒绝）
git branch -D <name>              # 强制删除分支

分支命名规范

前缀	用途
feature/*	新功能开发
bugfix/*	缺陷修复
hotfix/*	紧急生产修复
release/*	版本发布
refactor/*	代码重构
docs/*	文档更新
chore/*	维护性任务

分支生命周期（六步）

1. 新需求 —— 功能 / bug修复 / 版本回滚……
2. 新建分支 —— 按上面的规范命名
3. 在分支上开发测试 —— 可产生多次提交
4. 合并到主分支

   git switch main          # 先切到主分支
   git merge feature/xxx    # 合并开发分支
   

5. 主分支测试 / 部署
6. 删除开发分支

保存现场（stash）

切换分支前工作区有未完成的修改时，先存起来：

git stash -u           # 保存工作区修改（-u 含未跟踪的新文件）
git stash -a           # 全部保存（连 .gitignore 忽略的文件也存，慎用）
# ... 切换分支处理其他事情，再切回来 ...
git stash list         # 查看储藏列表
git stash pop          # 恢复最近一次的储藏，并删除该记录
git stash apply        # 恢复最近一次的储藏，但保留记录
git stash pop stash@{n}  # 恢复指定的某次储藏

• pop = 恢复 + 删除记录；apply = 恢复 + 保留记录
• 省略 id 时默认操作最近一次保存的储藏（stash@{0}）

三种模式的区别：

命令	已跟踪的修改	未跟踪的新文件	被忽略的文件
git stash	✅	❌	❌
git stash -u	✅	✅	❌
git stash -a	✅	✅	✅

日常用 -u 即可：未跟踪的新文件不带走会留在现场，可能被误提交或引发冲突；而 -a 多带的忽略文件（如 node_modules）切分支时 Git 本就不会触碰，打包它们又慢，还容易在 pop 恢复时冲突。

分支为什么会分叉？

分支本质上只是指向某个提交的指针。两条分支从同一个起点出发、各自产生新提交，就分叉（diverge）了：

                A 先合并，main 前进
               ↓
main:   ●─────────────M1───────────────M2
         \             ↑               ↑
         └─ a1 ─ a2 ───┘               │
          \                            │
           └──── b1 ──── b2 ───────────┘

● = A、B 的共同起点

典型场景：A、B 同时基于 main 开发 ——

1. A 先完成，合并进 main → main 前进了
2. B 后完成，也往 main 合并 → B 基于的是旧 main，真正的分叉形成
3. Git 执行三方合并：找到共同起点，分别对比两边各改了什么
   • 改的是不同文件 / 不同行 → 自动合并，互不打扰
   • 改了同一文件的同一行（或相邻行） → Git 无法判断该听谁的 → 冲突，必须人工裁决
   • 一边删除文件、另一边修改了该文件 → 同样冲突

关键认知：分叉不必然冲突，"撞车"才冲突。冲突不是错误，是 Git 在求助——它发现两边都动了同一块地方，把决定权交还给人。

冲突解决

冲突必须手动解决，尤其是主分支的冲突。

合并时出现冲突后：

1. 打开冲突文件，找到冲突标记

   <<<<<<< HEAD
   当前分支的内容
   =======
   被合并分支的内容
   >>>>>>> feature/xxx
   

2. 手动编辑，保留正确内容，删除标记

3. git add <冲突文件> 标记为已解决

4. git commit 完成合并

常见场景实战

场景 1：开发到一半，要紧急修复线上 bug

正在 feature/payment 上开发，代码写了一半还不能提交，线上突然出 bug：

git stash -u                            # 1. 保存现场
git switch main                         # 2. 回到主分支
git switch -c hotfix/pay-bug            # 3. 建紧急修复分支
# ...修复、测试...
git add . && git commit -m "fix: 修复支付重复扣款"
git switch main                         # 4. 切回主分支
git merge hotfix/pay-bug                # 5. 合并，主分支测试/部署
git branch -d hotfix/pay-bug            # 6. 删除修复分支
git switch feature/payment              # 7. 回到原来的开发分支
git stash pop                           # 8. 恢复现场，继续开发

场景 2：忘了切分支，直接在主分支上改了代码

改完发现所在分支是 main，还没提交，把改动"搬"到新分支即可：

git switch -c feature/xxx      # 未提交的改动会跟随带到新分支
git add . && git commit -m "feat: xxx"

前提：改动与目标分支不冲突。平时养成动手前先 git branch 确认所在分支的习惯。

场景 3：删除分支被拒绝

git branch -d feature/test
# error: the branch 'feature/test' is not fully merged

这是 Git 在保护你：分支上有未合并的提交。先确认这些改动确实不要了，再强制删除：

git branch -D feature/test