分支与合并

要做一个大改动、或想试个新想法又怕搞坏主线？开个分支——改崩了主线毫发无伤，成了再合并回来。冲突它自动解，您只管拍板。

分支是什么（30 秒版）

把项目想象成一条时间线（主线）。分支 = 从某个点岔出去的另一条时间线——您在岔路上随便折腾，主线纹丝不动；折腾成了，把岔路并回主线。

场景	用法
大重构 / 新功能，要做几天	开分支做，主线随时可用；做完合并回来
试个想法，不知道行不行	开分支试，不行整条扔掉，零清理成本
多人协作	各开各的分支，互不干扰，最后各自合并
修紧急 Bug	主线开个修复分支，修完先合主线——比在大改动里找空子稳

什么时候需要您操心分支

多数时候不用——单人小项目直接在主线上小步提交（见提交与推送代码）就很好。分支在这几个信号出现时才值得开：

• 这个改动大（几十个文件、好几天）
• 这个改动险（重构核心、换技术栈）
• 多人同时改同一个仓库
• 您明确想保留退路：「失败了就当没做过」

开分支：一句话的事

开一个分支 feature/export-report 做导出功能，
在这个分支上改，别动主线。

它建分支、切过去、开始干活——之后的提交都落在这条分支上。您在源代码管理面板能看到当前在哪条分支（分支标识常显）。

合并回来：冲突自动解

分支上做完、验证过，说一句：

导出功能做完了，合并回主线。

合并时如果主线也改过同一处，就产生冲突——这时自动进入 AI 冲突解决：

1. 冲突文件按前端 / 后端智能分组，并行解决
2. 每组解完自动校验（编译、测试过得了关才算解完）
3. 两边改成了两种业务意图、机器不敢替您拍板的，才挂起问您

✅ 看到什么算成功

合并完成的消息里带合并摘要——哪些文件并了、冲突几处怎么解的、合并后测试是否通过。主线历史里出现一条合并记录。

分支的日常操作

您想做	怎么说 / 怎么点
看有哪些分支	源代码管理面板分支菜单——列表全在
切回主线继续别的活	「切回主线」或分支菜单点选
这条分支不要了	「删掉 feature/xxx 分支」——已合并的删了不丢代码
看分支上做了什么	「这条分支上有哪些提交」——它列出该分支的历史
放弃分支上的所有改动	「这条分支整个不要了，回主线」——主线无恙

与回退的配合

分支本身就是最强的「后悔药」——实验性改动开分支做，失败了删分支即可，连回退都省了。已合并进主线的部分，按提交历史回退。

常见卡点

现象	怎么办
不知道现在在哪条分支	面板分支标识常显；或问它「现在在哪个分支」
合并冲突解得不对	冲突解决有对照记录；不认可的地方指出，它按您的口径重解
分支做一半要切走处理急事	直接切——分支上的改动原地保留，回来接着做
想同步主线的最新进展到分支	「把主线的更新合到我这条分支」——它做反向合并
删错了分支	已合并过的分支删了代码不丢（都在主线）；未合并的分支删除前它会提醒

延伸阅读

• 提交与推送代码：分支上的日常提交与推送
• 改错了怎么回退：三档回退与分支的配合
• 接手老项目与二次开发：多分支老仓库怎么理