katzchang/gist:4126092

## gistfile1.md

      
    Raw
  

              gistfile1.md
            
          
    ということで、ffマージはなぜ優れているかというと、マージ操作の際に機械的な構成変更が一切行われず、ブランチの移動が起こるのみなので、マージ後のブランチは、 必ず あなたが入念にテストしただろうマージしたブランチと全く同じ構成であることが保証されるわけである。これが大きい。
衝突検知をくぐり抜けて機械的マージが構成を壊してしまう例は他をご参照いただくとして、no-ffマージの場合にそういう面倒に対応する手段として次のようなものがあると思うが、いずれも確実性でffマージには劣る：

マージ前にバックマージを行い、マージ時の際をなくする
バックマージからマージまでの間に誰かのコミットが入るかもしれないので、たまに衝突したときのことも考えないとね
マージ後のテストで問題を発見し、修正をコミットする
修正って場合によっては時間がかかる仕事でそのあいだmasterは不安定だし、マージ権限を持つ人が少数だとしたら負担でかいよね

ということで、どちらもffマージの恩恵を考えると、なかなか悩ましい。
ただ、とくに少数チームでは実際にこれらが起こって実害につながるケースはあんまりないし、githubのpull request機構はレビュー基盤としてとてもとても便利なので、今はそれにあやかっています。といっても、一度、無衝突マージ後ビルドが壊れたことはあったので、十分な自動テストカバー率が求められるところだと思う。ビューも関係するとかなり難しいけど。
もう一つのffマージに寄せられる欠点として、明確なマージコミットがないのでmasterの遍歴がわかりにくく、万が一のマージのrevertが難しいという話もある。これに対しては、安定版ビルドにタグ打つなり、リリースでタグを打てば足りるし、もちろんそれはJenkinsおじいちゃんなりデプロイツールなりが良い感じに打つことは、さほど難しくないはず。
リリース済みのものに対して緊急的な不具合が見つかった場面では、とりあえず安定版リリースに戻すことを優先し、revertもしくは修正の対応は落ち着いて対応しつつ、対応でき次第再度リリースすればいい。これはどのマージ戦略をとっても同じなはず。revertする場合、どちらのマージ戦略でも安定版までの差分をrevertすることになるので、revert対象が1コミットか複数コミットかの違いはあるが、それは大きな問題だとは思わない。蛇足だけど、「安定版リリースに戻す」っていう操作は普段の操作ではないので、訓練なりしつつ、慣れておく必要があるようだ（うちのチームではそうだった。あなたは？）。
ということで何が言いたかったかというと、ffマージは他にない強力な利点があるということと、rebaseはffマージをさせるためにあるのであって、コミット履歴のクリーンアップはおまけですよということが言いたいのでありました。
とはいえ、githubのpull request便利ですよね。