（自己的老博客搬运）createdAt：2016-12-14 20:35:43
前言
本来没想到分支能写这么长的。。于是就拆成两篇了~想看另一篇的可以 戳这里 git分支管理(一)---创建、提交、切换
指针机制
git 的每个commit都是一个节点，每条分支都有一个head指针指向该分支最新的节点。 比如下图有紫色分支和绿色分支，每个圆圈是一个commit节点，红色外框的圆圈是该分支的head指针指向的节点。
- 紫色是master分支，绿色是dev分支
两种合并方式
-
Fast Forward
--ff
这是一种当其中一个分支没有新节点时的默认的合并方式（以下简称FF）
(就是你不必加--ff这个参数，如果可以用这种方式合并git自然会用这种方式的)
git merge dev
# 当前在master分支下，执行此命令会默认进行fast forward 合并
# 将dev合并到master
# 合并之后提交线变成一条线，两个分支的head是同一个节点
-
Not Fast Forward
--no-ff
git merge --no-ff dev
# 新建一个节点！
# 合并之后依旧可以从提交线中清晰地看出不同分支的commit历史
# dev分支的head没有变哦
-
执行完这个指令会进入vim，让你输入新节点要commit的信息
-
作为一个刚会用vim没多久的小白。。贴一下vim基本用法好了~~
-
输入
i之后允许输入；输入结束后按Esc；:wq保存并退出vim -
两者比较
最主要的差别其实就是提交线图不同：FF是一条线，noFF是多条线。
NoFF的优点很强势~
比如项目开发过程中，一般都是用master放比较稳定的代码，而在另外创建一个分支上写代码，测试好了再合并到master上。可能会有不同的功能点用不同的分支啊，或者不同的开发者用不同的分支之类的。如果是NoFF合并，就可以用git可视化工具清晰地看到各个分支的详细情况，便于追踪。
比如下图是我上学期的一个大作业。我们团队四个人的提交线的部分(一个master和每人一个分支)~
而如果是FF合并就惨了。。都在一条线上。。很难找的~
不过要是很小型的项目的话用FF会省事一点喽，就不用每次合并都搞一个新节点出来~ 自己视情况权衡利弊吧 ^ ^
-
总结
写这篇博客之前查了好多资料，好多人说FF合并，分支删掉之后会丢失分支信息，我当时还以为是节点会丢失~ 然而亲测并没有。
所以猜测那些人指的应该是会丢失分支的独立性吧（就是都混在一起看不出谁是谁啦> <）~
我还试了一下，两个分支如果相对于分离点都有新节点(就像本文的第一张图)，但是改动的代码没有冲突，git会不会默认使用FF合并。
亲测不会。而且我还试着加
--ff参数强制FF合并，也还是执行了NoFF合并~就这些吧~等哪天研究一下git提交冲突的再来发文~~
PS：为了测试各种情况，快看我今天github上activity程度哈哈哈~创我历史新高~~~
参考：
