前言
git-merge 有可能是最難搞清楚的，又是最常遇到的一個命令，其實這麼想來，原來 SVN 時代、 CVS 時代，衝突都是一個不好解決的問題；或者說，衝突是最難自動解決的一個問題了，無論是在代碼中，還是實際生活中。
博客
原帖收藏於IT老兵驛站。
正文
git-merge 使用來把兩個或更多的開發歷史合併。
參考裏面是官網的講解，這個帖子，我看了可能至少有五六遍了，但是要是說完全掌握明白，好像還是沒有。
這兩天又閱讀了幾遍，似乎看明白了一點。
git merge [-n] [–stat] [–no-commit] [–squash] [–[no-]edit] [–no-verify] [-s ] [-X ] [-S[]] [–[no-]allow-unrelated-histories] [–[no-]rerere-autoupdate] [-m ] [-F ] […]
git merge (–continue | --abort | --quit)
僅僅就這個命令形式，我就看過了好多遍，就沒太看明白。
第一行是 git merge 的基本使用方式，而我理解和所使用到的方式就是在一個分支上，可以把另外一個分支的內容合併過，但是這裏都沒有出現。
Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch. This command is used by git pull to incorporate changes from another repository and can be used by hand to merge changes from one branch into another.
這裏寫的是，merge 是把那些從當前分支開始分出去的提交合併到當前分支。這也是 git pull 所使用的方式。從這個角度來說，倒是能說的通上面的問題。
第二行是如果你執行了上面的第一行命令，可能就會處於一種需要選擇的狀態，談不上進退兩難，但我之前的情況是更多是要選擇後退。
Warning: Running git merge with non-trivial uncommitted changes is discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict.
有趣的是，這段話提醒了我，造成這個問題的原因有可能是因爲有太多的內容需要合併----那其實思路還是一樣（和寫代碼很多地方的思路是一樣的），就是小步地提交，頻繁地合併。
-s
–strategy=
Use the given merge strategy; can be supplied more than once to specify them in the order they should be tried. If there is no -s option, a built-in list of strategies is used instead (git merge-recursive when merging a single head, git merge-octopus otherwise).
-X
–strategy-option=
Pass merge strategy specific option through to the merge strategy.
這段是需要搞明白的內容，合併的策略是什麼，就是 git 怎麼去合併呢？git是有一些內建策略的。
確認了策略，然後可以確認策略的選項。
另外一篇文章《Git：merge的時候全部採用某一個端的文件》是原來總結的一篇文章，總結了一種 merge 的用法，那篇文章只是從很小的一個片段去總結了一下。
Recursive git merge -s recursive branch1 branch2 This operates on two
heads. Recursive is the default merge strategy when pulling or merging
one branch. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies. This is the default merge strategy when pulling or merging one branch.
Resolve git merge -s resolve branch1 branch2 This can only resolve two heads using a 3-way merge algorithm. It tries to carefully detect cris-cross merge ambiguities and is considered generally safe and fast.
上面是兩種最常見的合併策略，還沒有完全看明白區別。
參考
https://git-scm.com/docs/git-merge
https://www.atlassian.com/git/tutorials/using-branches/merge-strategy