git - Gitのリベースまたはマージ

Question

ベースブランチに修正を追加して他のすべてのブランチに配置する場合は、リベースが適していることを理解しています。しかし、それはマージよりもはるかに複雑に見えます（はるかに多くの競合）。私は何かが足りないのですか？

Answer 1

一般に、git rebase公開されていないもの、つまり自分がプッシュしていない（または他の人が引っ張っていない場所にプッシュした）ローカルなものに取り組んでいる場合に使用することをお勧めします。リベースは履歴を書き換えるので、リベースするとプルする人に問題が発生しますが、マージでは履歴が書き換えられないため、他の人に問題は発生しません。

マージはマージ戦略を使用して変更をマージしようとしますが、リベースはリベース対象のHEADをフェッチしてから、変更を適用しようとします。変更が行われた時間が失われるため、マージほど効果的に競合を解決することはできません。

通常、リベースはそれほど複雑ではありません。ただし、比較的小さなコードベースで、多くの開発者が同時に作業し、お互いに足を踏み入れている場合や、コードを長時間放置している場合を除きます。

これはリベースについて読むのに良いリソースだと思います：http ：//www.jarrodspillers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html

Jarrodは、「リベースルール」を非常によく定義しています。別の開発者と共有しているブランチをリベースしないでください。

Answer 2

彼らが彼らを知る前に、リベースは人々を怖がらせます。これが実際にリベースとマージの間の素晴らしい要約です：リベースのリベースコミットの最後であるか、マージ後の最後のマージコミットであるかにかかわらず、最終的なコミットが指すスナップショットは同じスナップショットであることに注意してください–異なるのは歴史だけです。リベースは、ある作業ラインから別の作業ラインへの変更を導入された順序で再生しますが、マージはエンドポイントを取得してそれらをマージします。

Answer 3

正当性の観点から、唯一の有効な答えはmerge次のとおりです。コミットを他のコミットにリベースすると、開発中に存在しなかった状態の新しいコミットが作成されます。テストされていない可能性が高い状態。コンパイルすらできないか、他の方法で無意味である可能性があります。

例：関数を呼び出すコードを分岐して開発しますfoo()。翌日、別の開発者があなたにfoo()いくつかの問題があると言いました。そのため、彼は現在それを削除しているところです。したがってfoo()、別のコミットでの呼び出しを削除し、機能の終了に進みます。ここで、ピアによって削除されたマスターに作業をリベースすると、操作で競合が発生しなくfoo()ても、初期のコミットはコンパイルされません。rebase

この例は、リベースされた履歴が嘘をついているという事実を示しています。これは、開発の履歴を正確に伝えるものではありませんが、開発が線形プロセスであるという幻想であなたを欺きます。そして、これらの嘘は結果をもたらします。gitマージ用に設計されており、そのように使用するのが最適です。