今天研究了一下git merge命令常用參數，並分別用簡單的例子實驗了一下，整理如下：
輸入命令git merge -h可以查看相關參數：
--ff 快速合並，這個是默認的參數。如果合並過程出現沖突，Git會顯示出沖突並等待手動解決
--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
結果：master分支會比dev分支多一條提交記錄，也就是剛才輸入犯人合並信息
4.執行：git merge --squash dev
master：C1 ← C2 ← C5 (Merge branch 'dev')
dev：C1 ← C2 ← C3 ←C4
結果：這里的C5其實是C3和C4的合並，如果只想合並dev的內容但是不需要它的提交記錄就可以用這個參數
第二種情況，切出后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是如何知道兩個文件有沖突呢？
這里先說下結論，有時間再補一篇文章單獨說明說明。
大家都知道在Git里每個文件都是一個blob對象，這里先不管合並時怎么找到同一個文件在兩個分支上的blob（其實如果文件沒有更新，在兩個分支上是指向同一個blob），假設現在已經到了比較階段了，Git會拿兩個文件來逐行進行對比，但是判定是否修改是通過相鄰行來確定的。也就是說文件a的第三行修改了，Git是通過第2行和第4行的對比來判定的，不信的可以先自己做實驗驗證。由於篇幅原因，這里不再贅述。
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就不會。