记一次github分支合并没有新建节点问题
前言
记一次 github 分支合并没有新建节点问题
正文
场景复现
虽然基本上是我一个人开发，但是还是要养成建分支的习惯
一方面熟悉命令行操作，一方面也可以养成自己的一套工作流
现在我个人的工作流是：
主分支 master
修复 bug 直接在 master 上进行 commit
新的需求的话就创建新的分支 feat/XXX需求
然后在这个分支上进行开发，开发完成之后，在 master 分支上执行 git merge feat/XXX需求
前几次基本没什么问题，但是最近的一次出现了 merge 没有额外的节点问题
我们可以创建一个项目来复现这个现象
从图里可以看到，我们进行了第一次提交
接着我们创建一个新的分支 git checkout -b feat/01需求
然后修改 README.md
从图上可以看到
此时还没有提交，那么现在我们执行 git add . && git commit -m "feat: 完成01需求"
这时候我们执行 git log --oneline --graph 来查看提交情况，如下（这里使用 vscode 的插件可视化查看）
然后我们切换为 master 分支，执行 git merge feat/01需求
然后再执行 git log --oneline --graph 查看提交情况
此时的提交记录是扁平的
但是我们想要的样子是想入如下图所示的
那这是为什么呢，在 merge 操作的时候我们可以看到命令行输了了 Fast-forward 这个字符串
这是 merge 的一个模式
在 git 中有这么几种 merge 模式
--fffast-forward默认的合并模式--no-ffno-fast-forward也就是fast-forward的相反模式--ff-only只允许fast-forward，如果无法使用则报错--squash压缩commit信息， 和no-ff互斥
什么是 fast-forward 模式
简单点讲：就是如果 merge 可以直接移动指针的话，此时就是 fast-forward 模式
可以通过一个简单的例子来说明
- 此时存在一个
master分支 - 在
master分支上新建了一个dev分支 - 在
dev上进行提交 - 回到
master - 把
dev合并到master上
此时 master 并没有新的提交，可以直接把 master 的指针直接指向 dev 的最后一次 commit 的节点
此时就是 fast-forward 模式
这种模式不会生成一个 commit 信息，意味着如果删除 dev 分支，那么提交信息会消失
我们可以用之前那个复现的 demo 来测试
执行 git branch -D feat/01需求 来删除 feat/01需求 分支
此时分支信息已经不见了
如果我们不适用 ff ，那么删除分支不会影响到提交信息，因为合并产生了一个节点
删除分支可以理解为只是删除一个指针而已
不使用 ff 删除 feat/01需求 分支后如下
此时依然可以看出来是从哪个分支进行合并的，分支的删除不影响提交的信息
什么是 squash 模式
有时候我们新开一个 fix 分支，修复了一些 bug
但这个分支其实我们并不想提交到远端，我们只想把修改的代码提交到 master 上，然后生成一次提交而已
--squash 就可以完成这种功能
--squash 并不会进行指针的移动（--ff），也不会进行分支的合并（--no-ff）
它只是把 fix 分支上的代码 add 到 master 上而已
然后在 master 上就可以使用 git commit 来进行提交
我们可以用之前的 demo 来测试这个参数
此时的 graph 如下
在 master 上执行 git merge feat/01 --squash
此时生成一个未 commit 的状态
此时就可以使用 git commit 来进行提交了
