今天研究了一下git merge命令常用参数，并分别用简单的例子实验了一下，整理如下：
输入git merge -h可以查看相关参数：
--ff 快速合并，这个是默认的参数。如果合并过程出现冲突，Git会显示出冲突等待手动解决或者abort此次merge
--ff-only 只有能快速合并的情况才合并。如果合并过程出现冲突，Git会自动abort此次merge
--no-ff 不使用快速合并。会生成一次新的提交记录，这个记录只是标识在这里进行了一次merge操作
--squash 压缩合并。将待合并的分支的内容压缩成一个新的提交合并进来
接下来举例说明，C代表一次提交，合并时都是将dev分支合并到master。
第一种情况：master分支切出dev分支后没有新的提交，也就是说只有dev分支有更新，可以快速合并：
eg：master：C1 ← C2
↑
dev： C3 ← C4
1.执行：git merge --ff dev
master：C1 ← C2 ← C3 ← C4
dev：C1 ← C2 ← C3 ←C4
查看git log时master分支会看到dev分支上的所有提交，此时master和dev是一样的
2.执行：git merge --ff-only dev
结果同上。
3.执行：git merge --no-ff dev
git会提示让你输入此次合并的信息，然后生成一个特殊的commit。
master:C1 ← C2 ← C3 ← C4 ← C5 (Merge branch 'dev')
dev：C1 ← C2 ← C3 ←C4
4.执行：git merge --squash dev
master：C1 ← C2 ← C5 (Merge branch 'dev')
dev：C1 ← C2 ← C3 ←C4
第二种情况，切出后master和dev分支均有更新，这种情况是最常见的。这里为了演示冲突，在C4和C5分别对一个文件进行了修改。
eg：master：C1 ← C2 ← C4
↑
dev： C3 ← C5
1.执行：git merge --ff dev
这时Git会告诉你产生了冲突并列出冲突的文件，查看文件时会列出具体冲突内容，这时要先解决冲突（如果使用Intellij Idea或Eclipse等工具，可以直接选择use ours/theirs，ours代表被合并分支即master，theirs代表合并分支即dev），然后将这些修改的部分提交，再执行merge操作。
master：C1 ← C2 ← C3 ← C5 ← C4 ← C6 (解决冲突的那次提交)
dev：C1 ← C2 ← C3 ←C5
那么问题来了，Git是如何知道两个文件有冲突呢？下篇文章详细说明。
2.执行：git merge --ff-only dev
这时Git会检测到产生了冲突，所以提示：Not possible to fast-forward, aborting. 即取消这次merge操作。
3.执行：git merge --no-ff dev
结果同1，不过这里在解决了冲突执行commit操作后不用再进行merge操作了。如果再执行merge操作，它会提示：Already up-to-date.
4.执行：git merge --squash dev
master：C1 ← C2 ← C4 ← C6 (解决冲突的那次提交)
dev：C1 ← C2 ← C3 ←C5
这里解决了冲突并提交之后也不用再执行merge操作了。如果再执行merge操作会有两种情况：
a.刚才解决冲突时选用了master分支的修改，那么还是会提示有冲突需要解决。
b.刚才解决冲突时选用了dev分支的修改，那么会提示Already up-to-date。
对比发现，使用--squash参数时，如果有冲突，解决完冲突后只要两个分支不完全一样，再执行git merge --squash时还是会进行merge。但--no-ff就不会。