ワークフローに存続期間の短いブランチが多数あり、それらを分離したいと考えています。ということで、使う予定git config --add merge.ff falseです。ただし、プルを実行している場合 (フェッチとマージであると理解しています)、ここで不要な余分なコミットを避けるために、早送りの動作が必要です。
これは良いことですか？これは可能ですか？
質問する
15407 次
1 に答える
23
注: Git 2.0 (2014 年第 2 四半期) では、コミット b814da8 a configが導入されpush.ffます。
pull.ff::
デフォルトでは、現在のコミットの子孫であるコミットをマージするときに、Git は追加のマージ コミットを作成しません。代わりに、現在のブランチの先端が早送りされます。
- false に設定すると、この変数は、そのような場合に追加のマージ コミットを作成するように Git に指示します (コマンド ラインから --no-ff オプションを指定するのと同じです)。
- only に設定すると、そのような早送りマージのみが許可されます (
--ff-onlyコマンド ラインからオプションを指定するのと同じです)。
最初の回答 (2012 年 10 月)
次を試してください。
git pull --ff
マージ構成設定で優先する必要があります。git pull コマンド内の基になるマージにオプションを
渡します。--ff
ただし、 「Git ワークフローを理解する--no-ff」で説明されているように、オプションに注意してください。
十分なフラグがあれば、Git が望んでいる方法ではなく、本来あるべきだと思う方法で動作するように強制できます。しかし、それはドライバーをハンマーのように使うようなものです。それは仕事を成し遂げますが、それはうまくいかず、時間がかかり、ドライバーを損傷します.
一般的な Git ワークフローがどのように崩壊するかを考えてみましょう。
Create a branch off Master,
do work,
and merge it back into Master when you’re done
ほとんどの場合、これは期待どおりに動作します。これは、分岐後に Master が変更されたためです。その後、ある日、フィーチャー ブランチをマスターにマージしましたが、マスターは分岐していません。マージ コミットを作成する代わりに、Git はマスターにフィーチャー ブランチの最新のコミット、つまり「早送り」を指示します。(図)
残念ながら、あなたの機能ブランチにはチェックポイント コミットが含まれていました。これは頻繁なコミットであり、作業をバックアップしますが、不安定な状態のコードをキャプチャします。現在、これらのコミットはマスターの安定したコミットと見分けがつきません。災害に簡単にロールバックできます。
そこで、新しいルールを追加します
–no-ff。これで作業が完了し、先に進みます。ある日、本番環境で重大なバグを発見し、いつ導入されたかを追跡する必要があります。実行します
bisectが、チェックポイント コミットに到達し続けます。あなたはあきらめて手で調べます。バグを 1 つのファイルに絞り込みます。
blame過去 48 時間でどのように変化したかを確認するために実行します。あなたはそれが不可能であることを知っていblameますが、ファイルが何週間も触れられていないことを報告しています. マージされたときではなく、最初のコミット時のレポートの変更
が判明しましblameた。あなたの最初のチェックポイント コミットは数週間前にこのファイルを変更しましたが、変更は今日マージされました。バンドエイド、壊れた
no-ff二等分、責任の謎はすべて、ドライバーをハンマーとして使用しているという症状です.
詳細については、次を参照してください。
于 2012-10-09T11:24:40.657 に答える