Git 学习笔记 - 合并
-
- [一、 合并的核心逻辑](#一、 合并的核心逻辑)
- [二、 合并选项列表详解](#二、 合并选项列表详解)
- [三、 总结:如何选择?](#三、 总结:如何选择?)
| 合并窗口 | 参考原版(有点老) |
|---|---|
![]() |
![]() |
当前窗口用于将 merge_20260410 分支合并到当前的 dev_jerry_kuafu
一、 合并的核心逻辑
在点击任何按钮之前,必须明确 Git 合并的三个底层逻辑,这能避免 90% 的误操作:
- 方向性 :合并操作是将
从合并进当前。在打开合并界面前,我们必须确保已经 Checkout(切换) 到了目标分支
(例如:想把代码合入main,就必须先站在main上)。 - 工作区状态 :强烈建议在工作区干净 (所有改动已提交或 Stash 暂存)的情况下执行合并。
这样如果合并效果不理想,可以随时无损中止(Abort)。
二、 合并选项列表详解
| 选项名称 | 官方定义与功能 | 适用场景与建议 |
|---|---|---|
| 不勾选(默认快进) | 如果满足 Fast-Forward(快进)条件则直接移动指针;否则创建一个 Merge Commit。 | 日常开发。多数情况下的首选,让 Git 自动判断最简单的合并路径。 |
| 并合 (Squash) | 将源分支所有提交压缩成一个修改,但不保留源分支的 Parent 指针。 | 清理垃圾提交。如果在开发分支上有很多无意义的提交(如 "fix typo"),合入主干时勾选它,主干只会看到一个整洁的提交。 |
| 非 Fast Forward | 即使可以简单移动指针,也强行创建一个新的合并提交记录。 | 功能上线/版本归档。能让 Git 图谱清晰地显示出"这里曾拉出一个分支,后来又并回来了",方便追溯完整功能。 |
| 不提交 | 合并完文件后停留在暂存区,不自动生成 Commit 记录。 | 二次检查。如果担心合并后逻辑有误,想在正式提交前先本地运行一下项目测试,勾选此项。 |
| 信息 | 自动从源分支抓取指定数量的提交说明填充到当前的合并注释框中。 | 文档自动化。当合并了很多小改动,懒得手动写合并总结时,用它来自动生成变更列表。 |
| 仅快进式 | 不能快进就直接报错。 | 同步上游。当只想纯粹拉取远程最新代码,不希望在本地产生复杂的交织线时使用。 |
Fast-Forward(快进) : 连个分支在同一条路径上,不存在冲突,只需要移动指针就能实现当前分支指向源分支的位置。
仅快进式 :当前分支从源分支出来,当前分支没有过任何提交,(但凡当前分支有提交,直接报错)。适合测试工程师使用。
三、 总结:如何选择?
为了保证项目的稳定性,建议遵循以下选择策略:
- 追求历史清晰度 :如果你希望在以后的
Log图谱中能一眼看出哪个功能是哪天合并的,请养成勾选 No Fast Forward 的习惯。 - 追求主干整洁度 :如果是由于个人尝试性开发产生的零碎代码,建议使用 Squash,这能避免主干分支被几百个"测试"提交淹没。
- 规避风险 :如果你对合并后的代码信心不足,勾选 No Commit,在本地编译、跑一下 Lua 脚本确认无误后,再手动在 TortoiseGit 中点击 Commit。
- 遇到冲突 :切记 Local 是自己。在处理数值 Excel 导出的 Lua 文件冲突时,务必仔细比对,防止数值回滚。
小贴士 :合并完成后,务必养成看一眼
Git Log视图的习惯,确认合并的"连线"符合你的预期。

