Git マージを使用すると、fast-forward ブランチ マージと fast-forward なしのブランチ マージを実行できます。fast-forward マージをいつ使用し、いつ fast-forward なしのマージを使用するかについてのアイデアはありますか?
ベストアンサー1
この--no-ffオプションは、機能ブランチを明確に把握したい場合に便利です。そのため、その間にコミットが行われなかったとしても、FF は可能です。ただし、メインラインの各コミットを 1 つの機能に対応させたい場合もあります。そのため、多数のコミットを含む機能ブランチを 1 つのユニットとして扱い、それらを 1 つのユニットとしてマージします。 で機能ブランチをマージすると、履歴からそれが明らかになります--no-ff。
そのようなことを気にしないのであれば、おそらく可能な限り FF で済ませることができるでしょう。そうすれば、ワークフローは SVN のような感覚になるでしょう。
例えば、この記事彼はその--no-ffオプションがデフォルトであるべきだと考えており、その理由は私が上で概説したものに近いです。
「feature」ブランチ上の一連のマイナーコミットが集まって 1 つの新しい機能を構成している状況を考えてみましょう。 を使用せずに「git merge feature_branch」を実行するだけでは--no-ff、「Git 履歴から、どのコミットオブジェクトが一緒に機能を実装したかを確認することは不可能です。すべてのログメッセージを手動で読む必要があります。 機能全体 (つまり、コミットのグループ) を元に戻すのは、本当に面倒です [--no-ffを使用しない場合]。一方、--no-ffフラグを使用すると、簡単に元に戻すことができます [コミットが 1 つだけであるため]。」
