67

成功した Git 分岐モデル--no-ffでは、分岐をマージするときに使用することをお勧めします。

この--no-ffフラグにより​​、マージが早送りで実行できる場合でも、マージは常に新しいコミット オブジェクトを作成します。これにより、機能ブランチの歴史的な存在に関する情報が失われるのを回避し、機能を一緒に追加したすべてのコミットをグループ化します。[…]

はい、さらにいくつかの (空の) コミット オブジェクトが作成されますが、そのコストよりもはるかに大きなメリットがあります。残念ながら、私は--no-ffまだ git merge のデフォルトの動作をする方法を見つけていませんが、そうすべきです。

ただし、 Git ワークフローを理解するためには、以下を使用しないことをお勧めします--no-ff。

そこで、新しいルールを追加します –-no-ff。これで作業が完了し、先に進みます。[…]

--no-ffバンドエイド、壊れた、bisect謎blameはすべて、ドライバーをハンマーとして使用しているという症状です。[…]

どちらのアプローチも、異なるシナリオでは妥当に思えますが、「優れた方法」と見なされるものは何ですか?

いつ使うか--no-ff、いつ使わないか、なぜ?

4

3 に答える 3

50

それはあなたがやろうとしていることに本当に依存しています。私の経験則では、マージが「何かを意味する」場合は、--no-ffオプションを使用します。マージが実際には何の意味もなく、リベースを使用した可能性がある場合、使用する理由はありません--no-ff。

git の利点は、非常に強力なツールであり、さまざまな方法で使用できることです。そのほとんどは間違っていません。それを行う「正しい方法」は何かを尋ねることは、絵を描く正しい方法は何かを尋ねるようなものです.

少なくとも私にとっては、コードでどのように協力したいかについてチーム内で頻繁に議論されており、私が好む一連の方法は進化しています.それが私たちのやり方です。

于 2013-08-08T14:02:44.120 に答える
4

それは、ワークフローと、ブランチの使用方法に大きく依存します。

開発中の "master" と 2 つの機能ブランチ "foo" と "bar" があるとします。

この場合、ブランチは異なる開発者が競合することなく作業できるようにするためだけに存在します。機能が完成したら、マスターにマージする必要があり、それらの機能が異なるブランチに実装されているかどうかを知ることは重要ではありません。

ただし、ブランチ「foo」と「bar」がシステム内の独立したモジュールを参照している場合、別のワークフローを持つことができます。

この場合、一部のコミットはモジュール スコープ外のファイルを変更する可能性があります。これら 2 つのブランチをマスターにマージすると、特定のモジュールの外側にあるファイルのログが混乱し、それらの変更がどこから来たのかを知るのが難しくなる場合があります。

ブランチのマージの履歴がワークフローにとって重要かどうかを判断する必要があります。

コメントに続いて、私はrebase、およびpull --rebaseワークフローを好みます。

于 2013-08-08T13:25:32.427 に答える