Gitワークフローの記事を理解すると、
そこで、新しいルールを追加します。「フィーチャー ブランチにマージするときは、–no-ff を使用して新しいコミットを強制します。」これで作業が完了し、先に進みます。
ある日、本番環境で重大なバグを発見し、いつ導入されたかを追跡する必要があります。bisect を実行しますが、チェックポイント コミットに到達し続けます。あなたはあきらめて手で調べます。
バグを 1 つのファイルに絞り込みます。過去 48 時間でどのように変化したかを確認します。それが不可能であることはわかっていますが、Blame はファイルが何週間も変更されていないと報告しています。マージされたときではなく、最初のコミット時に Blame レポートが変更されることが判明しました。あなたの最初のチェックポイント コミットは数週間前にこのファイルを変更しましたが、変更は今日マージされました。
ノーフバンドエイド、壊れた二等分、および非難の謎はすべて、ドライバーをハンマーとして使用しているという症状です.
git merge--no-ffは、早送りマージを明示的に防止する場合です。ただし、あるコミットが別のコミットの直接の祖先でない場合、早送りは行われません。これは、開発中のまれなシナリオです。つまり、ほとんどのマージは非早送りタイプです。では、渡すと and--no-ffの機能がどのように損なわれるのでしょうか?bisectblame