本文系统总结 Git 分支管理的核心问题和最佳实践，适合正在从"只会 commit/push"进阶到规范化开发流程的开发者。

---

目录

1. 为什么需要分支管理？

2. 分支命名规范

3. 单人开发工作流

4. 多人协作工作流

5. 常见问题与解决方案

6. Git 命令速查表

---

为什么需要分支管理？

想象一下这些场景：

• 你正在开发新功能，写到一半老板说有个紧急 bug 要修

• 你和同事同时修改了一个文件，提交时冲突了

• 你想试验一个新想法，但又怕搞坏现有代码

分支（Branch） 就是解决这些问题的利器。它让你可以：

✅ 在不影响主代码的情况下开发新功能 ✅ 多人并行开发互不干扰 ✅ 随时切换任务 ✅ 出问题时轻松回滚

---

分支命名规范

主要分支

分支名	用途	稳定性
main / master	生产环境代码，随时可发布	⭐⭐⭐ 最稳定
develop	开发主线，汇总最新功能	⭐⭐ 相对稳定

临时分支（用完即删）

前缀	用途	示例
feature/	新功能开发	feature/user-login
bugfix/	修复 bug	bugfix/crash-on-startup
hotfix/	紧急线上修复	hotfix/security-patch
release/	发布准备	release/v2.0.0

命名建议

# ✅ 好的命名
feature/add-recording-function
bugfix/fix-video-playback
hotfix/critical-memory-leak
​
# ❌ 不好的命名
new-feature
fix
test123

---

单人开发工作流

标准流程

┌─────────────────────────────────────────────────────┐
│  1. 确保在 develop 分支，拉取最新代码                │
│     git checkout develop                            │
│     git pull origin develop                         │
├─────────────────────────────────────────────────────┤
│  2. 创建功能分支                                     │
│     git checkout -b feature/你的功能名              │
├─────────────────────────────────────────────────────┤
│  3. 在功能分支上正常开发、提交                       │
│     git add .                                       │
│     git commit -m "feat: 添加xxx功能"               │
├─────────────────────────────────────────────────────┤
│  4. 开发完成，合并回 develop                         │
│     git checkout develop                            │
│     git pull origin develop  # 再次拉取，防止冲突    │
│     git merge feature/你的功能名                    │
│     git push origin develop                         │
├─────────────────────────────────────────────────────┤
│  5. 删除功能分支（可选）                             │
│     git branch -d feature/你的功能名                │
└─────────────────────────────────────────────────────┘

提交信息规范（Conventional Commits）

# 格式：<type>(<scope>): <description>
​
feat: 添加用户登录功能        # 新功能
fix: 修复视频录制崩溃问题     # 修复 bug
docs: 更新 README            # 文档
refactor: 重构事件检测模块    # 重构（不改功能）
style: 格式化代码            # 代码风格
test: 添加单元测试           # 测试
chore: 更新依赖              # 杂项

---

多人协作工作流

协作分支模型

main     ─────────────────●────────────────────●──────
                          ↑                    ↑
                       (发布)               (发布)
                          │                    │
develop  ────●────●───────●────●────●──────────●──────
             ↑    ↑            ↑    ↑
             │    │            │    │
feature/A ───●────┘            │    │   (开发者 A)
feature/B ─────────────────────●────┘   (开发者 B)

协作流程

1. 每人创建自己的功能分支

   git checkout develop
   git pull origin develop
   git checkout -b feature/我的功能

2. 定期同步 develop 的更新

   # 在自己的分支上
   git fetch origin
   git merge origin/develop
   # 或使用 rebase（更整洁）
   git rebase origin/develop

3. 完成后通过 Pull Request 合并

   • 推送到远程：git push origin feature/我的功能

   • 在 GitHub 创建 Pull Request

   • 请同事 Code Review

   • 合并后删除分支

代码审查（Code Review）要点

• ✅ 逻辑是否正确

• ✅ 是否有潜在 bug

• ✅ 代码风格是否统一

• ✅ 是否有测试覆盖

• ✅ 是否影响其他功能

---

常见问题与解决方案

问题 1：合并时出现冲突

场景：你和同事都修改了同一个文件的同一行

解决步骤：

# 1. Git 会提示冲突
Auto-merging src/app.cpp
CONFLICT (content): Merge conflict in src/app.cpp
​
# 2. 打开文件，找到冲突标记
<<<<<<< HEAD
你的代码
=======
同事的代码
>>>>>>> origin/develop
​
# 3. 手动编辑，决定保留哪些内容（或合并两者）
最终想要的代码
​
# 4. 标记为已解决
git add src/app.cpp
git commit -m "resolve merge conflict in app.cpp"

预防技巧：

• 频繁拉取 develop 的更新

• 划分清晰的代码职责，减少同时修改同一文件

---

问题 2：提交到了错误的分支

场景：本应在 feature 分支开发，却在 develop 上提交了

解决方案：

# 1. 记录当前提交的 hash
git log -1  # 记下 commit hash
​
# 2. 回滚 develop 上的提交
git reset HEAD~1  # 撤销最后一次提交，保留修改
​
# 3. 切换到正确的分支
git stash           # 暂存修改
git checkout feature/xxx
git stash pop       # 恢复修改
git add .
git commit -m "你的提交信息"

---

问题 3：想撤销已推送的提交

场景：推送了有问题的代码，想撤销

方案 A - Revert（推荐，安全）：

# 创建一个新提交来撤销之前的更改
git revert <commit-hash>
git push

方案 B - Reset + Force Push（危险，仅限个人分支）：

git reset --hard <要回到的commit>
git push --force  # ⚠️ 会覆盖远程历史，团队协作慎用！

---

问题 4：本地修改和远程有冲突，无法 pull

场景：git pull 报错，因为本地有未提交的修改

解决方案：

# 方案 A：先暂存本地修改
git stash
git pull
git stash pop
​
# 方案 B：先提交本地修改
git add .
git commit -m "WIP: 临时保存"
git pull

---

问题 5：不小心删除了分支

场景：误删了一个还需要的分支

解决方案：

# 1. 查看 Git 操作历史
git reflog
​
# 2. 找到删除前的 commit hash
# 例如：abc1234 HEAD@{2}: checkout: moving from feature/xxx to develop
​
# 3. 恢复分支
git checkout -b feature/xxx abc1234

---

问题 6：如何查看分支图

# 命令行查看
git log --oneline --graph --all
​
# 或使用 GUI 工具：
# - GitKraken
# - SourceTree
# - VSCode Git Graph 插件

---

Git 命令速查表

分支操作

操作	命令
查看所有分支	git branch -a
创建分支	git branch 分支名
切换分支	git checkout 分支名
创建并切换	git checkout -b 分支名
删除本地分支	git branch -d 分支名
删除远程分支	git push origin --delete 分支名
重命名分支	git branch -m 旧名 新名

同步操作

操作	命令
拉取更新	git pull origin 分支名
推送代码	git push origin 分支名
获取远程信息	git fetch origin

合并操作

操作	命令
合并分支	git merge 分支名
变基	git rebase 分支名
中止合并	git merge --abort
中止变基	git rebase --abort

撤销操作

操作	命令
撤销工作区修改	git checkout -- 文件名
撤销暂存区	git reset HEAD 文件名
撤销提交（保留修改）	git reset --soft HEAD~1
撤销提交（丢弃修改）	git reset --hard HEAD~1
撤销已推送的提交	git revert <commit-hash>

---

总结

黄金法则：

1. 🌿 新任务 = 新分支 - 永远不要在 main/develop 上直接开发

2. 🔄 频繁同步 - 定期拉取 develop 的更新，早发现冲突

3. 📝 清晰的提交信息 - 让未来的自己和同事能看懂

4. 🔍 Code Review - 多人项目必须经过审查再合并

5. ⚠️ 慎用 force push - 除非你100%清楚在做什么