GitHub マージ方法の違いを調べた
これまで仕事でマージ方法を指定されたことがないのでマージコミットを作成する方法でマージしていたけど
そろそろ他の種類も理解しておいた方が良さそうなのでGitHubで提供されている3つのマージ方法を試してみた！
マージの準備として以下を行いました
masterからfeature/#1ブランチ作成してカレントブランチにする
コメント行を追加してfeature/#1にコミット・プッシュ
masterからfeature/#2ブランチ作成してカレントブランチにする
同じ箇所にコメント行を追加してfeature/#2にコミット・プッシュ
Create a merge commitでfeature/#1をmasterにマージ&プッシュ
Create a merge commit
Create a merge commit でfeature/#2をmasterにマージしようとすると先ほどマージした箇所と競合します
Create a merge commit を選択すると手動マージしてくださいとのこと（競合箇所が多いと焦るあるあるですね）
Atomで競合箇所を確認してfeature/#2の修正を選択しマージ・プッシュ！
マージ先のmasterは新たに作成されたマージコミットの状態になっている（non fast-forwardマージ）
featureブランチを削除してもマージ履歴は枝分かれしています（このマージだったらfeature削除しないほうが履歴が追いやすくて良さそう）
Squash and merge
再び上記の準備を実施した状態（今度は#3、4ブランチ）
Squash and merge を選択し先ほど同様に手動マージを行いfeature/#4をmasterにマージ&プッシュ
このマージ方法だと#4ブランチは枝分かれしたままで#3ブランチに#4の修正点が付け足されています（こちらもnon fast-forwardマージになっている）
masterにマージした後featureブランチを削除すると修正が1本線でされたようになります（feature削除する場合はこちらが良さそう）
Rebase and merge
最後にrebase編！準備を実施（今度は#7、8ブランチ）masterは#7ブランチの状態
※#5、6でやってみたが動きがつかめなかったのでリトライ！
Rebase and merge を選択するとまずrebase実行のアラートが出て手動マージ
これまでのマージ方法ではour changesがマージしようとしているブランチの修正だったけどrebaseマージでは逆になっている
（#7ブランチをrebaseするからこちらの修正がour changesになるってことか！rebase解説はこちら）
feature/#8ブランチの修正を選択してマージ&プッシュ！masterはpull1件、push1件になっています
fork GUIでpullだけ実行しようとしたらまた競合が発生したのでgithub GUIでforce pushするとリモートmasterが#8の状態になった
featureを削除すると#7での修正履歴は消え、単純にmaster修正前→#8に修正されたように見える
rebaseマージの使いどころが分かっていないがfeatureブランチの修正範囲が大きくコミット回数が多いが、コミット履歴は不要という場合に使えるのかな？？
