Git早送りVS早送りマージなし

Question

Git merge早送りと早送りのブランチマージを実行できません。任意のアイデアは、早送りマージを使用する場合と、早送りマージを使用しない場合はどちらですか？

Answer 1

--no-ffオプションは、機能ブランチの明確な概念が必要な場合に便利です。したがって、コミットが行われていなくても、FFが可能です。メインラインの各コミットを1つの機能に対応させることが必要な場合もあります。したがって、コミットの束を1つの単位としてフィーチャーブランチを扱い、それらを単一の単位としてマージします。 と機能ブランチマージを行うことは、あなたの歴史から明らかです。

このようなことを気にしなければ、おそらく可能な限りFFで逃げることができます。したがって、より多くのsvnのようなワークフロー感覚が得られます。

たとえば、このarticleの著者は--no-ffオプションがデフォルトであるべきと考えていると彼の推論は、私が上に概説したものに近い。ここで、「機能」ブランチ上の軽微なコミットの一連の総称

を検討状況Git merge feature_branchをなしで実行すると、コミットオブジェクトのどれが機能を実装しているかをGitの履歴から見ることは不可能です。すべてのログメッセージを手動で読み取る必要があります。全体の機能（つまり、コミットのグループ）を元に戻すことは、真の頭痛[が使用されていない場合]ですが、フラグが使用された場合は簡単です忘れないで1つのコミット]。

Answer 2

これは、1つのコードはちょうど一日の終わりに置かれている機能ブランチをパーソナライズしているしたいことも可能です。これにより、より詳細な開発を追跡することが可能になります。

マスター開発を非正常なコードで汚染したくないので、--no-ffを実行するだけでよいでしょう。

パーソナライズされたブランチで作業コードをコミットする必要はないかもしれません。これは、他の誰も同じブランチで作業していない限り、履歴はgit rebase -iに書き換えられ、サーバー上で強制的に実行されるためです。

Answer 3

私はプロジェクトでよく見られる例を挙げることができます。

ここで、--no-ff（つまりtrue merge）は複数の親を持つ新しいコミットを作成し、より良い履歴追跡を提供します。そうでない場合は、--ff（つまりfast-forward merge）がデフォルトです。

$ git checkout master 
$ git checkout -b newFeature 
$ ... 
$ git commit -m 'work from day 1' 
$ ... 
$ git commit -m 'work from day 2' 
$ ... 
$ git commit -m 'finish the feature' 
$ git checkout master 
$ git merge --no-ff newFeature -m 'add new feature' 
$ git log 
// something like below 
commit 'add new feature' 
commit 'finish the feature'  // => commit created at merge with proper message 
commit 'work from day 2' 
commit 'work from day 1' 
$ gitk       // => see details with graph 

$ git checkout -b anotherFeature  // => create a new branch (*) 
$ ... 
$ git commit -m 'work from day 3' 
$ ... 
$ git commit -m 'work from day 4' 
$ ... 
$ git commit -m 'finish another feature' 
$ git checkout master 
$ git merge anotherFeature  // --ff is by default, message will be ignored 
$ git log 
// something like below 
commit 'work from day 4' 
commit 'work from day 3' 
commit 'add new feature' 
commit 'finish the feature' 
commit ... 
$ gitk       // => see details with graph 

（*）newFeature分岐が再使用されている場合、代わりに新しいブランチを作成するのではなく、Gitはとにかく--no-ffマージを行う必要があります、ここであることに注意してください。つまり、早送りマージは適格ではありません。