在多人协作开发中，Git的分支管理就像一条看不见的“交通规则”，让每个人的代码变更有序进行，避免混乱。如果没有规范的分支策略，团队成员可能会在同一个文件上互相修改，导致代码冲突、功能混乱甚至部署失败。这篇文章会用最简单的方式，让你理解为什么需要分支管理，以及如何在团队中规范使用Git。

为什么需要分支管理？¶

想象一下：你和同事同时在写一个项目，你改了login.js，同事也改了login.js，如果直接提交到主分支，就会出现代码冲突——系统不知道该保留谁的修改。更糟糕的是，如果你们都把代码直接推到主分支，主分支的代码可能随时被破坏，导致项目无法运行。

分支管理的核心作用是：让每个人在独立的“线路”上开发，互不干扰，最后再合并成果。就像一条主路（主分支）分成多条支路（功能分支），大家在各自的支路上修路，最后再把支路和主路连接。

Git分支基础：从“一条线”到“多线路”¶

什么是分支？¶

分支（Branch）本质上是代码的不同版本线。默认情况下，Git只有一条主分支，通常叫master或main（现在很多项目用main）。当你创建一个新分支时，相当于复制了当前的代码状态，你可以在这个新分支上自由修改，而不会影响主分支。

常用分支类型¶

• 主分支（main/master）：永远保持可部署的稳定代码，只接受合并，不直接提交代码。
• 功能分支（feature/*）：用来开发新功能，比如feature/user-center（用户中心功能）。
• 修复分支（bugfix/*）：用来修复线上问题或开发中的小bug，比如bugfix/login-error。
• 临时分支（hotfix/*）：紧急修复生产环境的bug（如服务器崩溃），需要优先合并到主分支。

最适合初学者的分支策略：简化版GitHub Flow¶

复杂的策略（如Git Flow）对新手来说门槛太高，这里推荐最简单的GitHub Flow，核心思想是：主分支永远可部署，所有功能通过“创建分支→开发→合并PR”完成。

1. 主分支（main）：永远“干净可用”¶

• 只有合并后的代码才能推到main，且main代码必须能直接运行。
• 禁止直接在main分支上提交代码（除非紧急修复）。

2. 功能分支（feature/*）：独立开发¶

• 创建分支：从main分支拉取最新代码，创建新功能分支。

  git checkout main  # 先确保在主分支
  git pull origin main  # 拉取最新主分支代码
  git checkout -b feature/user-center  # 创建并切换到功能分支

• 开发功能：在分支上写代码，定期提交。

  # 修改文件后
  git add .  # 添加所有修改
  git commit -m "feat: 完成用户中心页面布局"  # 提交信息规范见下文

• 推送分支：把功能分支推到远程仓库，方便团队协作。

  git push -u origin feature/user-center  # -u记住远程分支，后续可直接git push

3. 合并代码：通过PR/MR完成“代码审查”¶

• 在GitHub、GitLab等平台上，功能分支推到远程后，发起Pull Request（PR） 或 Merge Request（MR）。
• 团队成员会审查代码（检查逻辑、风格、是否有bug），通过后合并到main分支。
• 合并后：删除功能分支（本地和远程都删，避免混乱）。

团队协作规范：让所有人“心照不宣”的约定¶

1. 分支命名规则（清晰易懂）¶

• 功能分支：feature/功能描述（如feature/wechat-login）
• 修复分支：bugfix/问题描述（如bugfix/login-crash）
• 主分支：main（固定，不要改）
• 紧急修复：hotfix/生产bug（如hotfix/payment-error）

2. 提交信息规范（让别人秒懂改了啥）¶

提交信息要清晰，方便后续查日志或回滚。推荐约定式提交（Conventional Commits），格式：

<类型>[可选作用域]: <描述>
[可选正文]
[可选脚注]

• 类型：feat（新功能）、fix（修复bug）、docs（文档）、refactor（重构）、test（测试）。
• 示例：
• feat: 添加用户注册表单（新功能）
• fix: 修复移动端按钮点击无响应（修复bug）
• docs: 更新API文档说明（文档修改）

3. 开发流程：禁止“野路子”¶

• 禁止直接push到主分支：永远通过功能分支开发，再合并到主分支。
• 禁止频繁提交“大杂烩”：每次提交聚焦一个小功能或修复，方便代码审查和回滚。
• 定期同步主分支代码：开发中如果主分支有更新，及时拉取合并，避免后期冲突过大。

  git checkout feature/user-center
  git pull origin main  # 拉取主分支最新代码，合并冲突后再继续开发

4. 代码审查：避免“低级错误”¶

• 代码审查是团队协作的关键，能发现逻辑漏洞、安全问题，还能传递经验。
• 审查时关注：代码逻辑是否正确、是否符合项目规范、是否有重复代码。

常见问题与解决方法¶

1. 分支冲突怎么办？¶

如果多人同时修改了同一个文件，合并时会出现冲突。解决步骤：
1. 拉取主分支最新代码：git pull origin main
2. Git会提示冲突文件（如<<<<<<< HEAD标记你的修改，=======后是别人的修改）
3. 手动编辑冲突文件，删除<<<<<<<、=======、>>>>>>>，保留正确内容
4. 保存后提交：git add . + git commit -m "merge: 解决冲突"

2. 提交信息写错了怎么改？¶

如果还没推送到远程，直接修改提交信息：

git commit --amend -m "fix: 修正用户头像上传bug"

3. 分支太多太乱，怎么清理？¶

合并到主分支后，远程功能分支可以删除（在平台上点“Delete branch”）；本地不需要的分支也可以删除：

git checkout main
git pull origin main
git branch -d feature/old-feature  # 删除本地分支

总结¶

Git分支管理的核心是“规范”与“协作”：通过分支隔离开发，通过规范减少沟通成本，通过协作提升代码质量。对初学者来说，不必一开始追求复杂策略，先掌握简化版GitHub Flow，养成“功能分支开发→PR合并→及时清理”的习惯，就能避免团队协作中的大部分混乱。

记住：好的分支策略，能让团队像流水线一样高效协作，让每个开发者都能专注于自己的任务，而不是担心代码冲突或版本混乱。从今天开始，试试用规范的分支管理吧！