違いは何だgit mergeとはgit rebase？

もともと3つのコミットがあったとしA、B、C：

次に、開発者Danがcommitを作成しD、開発者Edがcommitを作成しましたE。

明らかに、この矛盾はどういうわけか解決されるべきです。これには、2つの方法があります。

MERGE：

両方のコミットDとEまだここにありますがM、両方Dとから変更を継承するマージコミットを作成しEます。しかし、これはダイヤモンド形状を作成し、多くの人々は非常に混乱します。

リベース：

commitを作成しますR。実際のファイルの内容は、M上記のマージコミットの内容と同じです。しかし、コミットEは存在しなかったように（ドットで示されている-消失線）、commit は取り除かれます。この抹消のためにE開発者Edのローカルであり、他のリポジトリにプッシュされてはなりません。リベースの利点は、ダイヤモンドの形状が回避され、歴史が良い直線に保たれることです-ほとんどの開発者はそれを愛しています！

私はgitについて嫌いな10の事柄からのこの抜粋を本当に気に入っています（2番目の例でリベースについて簡単に説明しています）：

3.不機嫌なドキュメント

manページは、万能の「f ***あなた」¹です。ユーザーではなくコンピューター科学者の観点からコマンドを説明します。適例：

git-push – Update remote refs along with associated objects

これが人間の説明です：

git-push – Upload changes from your local repository into a remote repository

更新、別の例：（cgdに感謝）

git-rebase – Forward-port local commits to the updated upstream head

翻訳：

git-rebase – Sequentially regenerate a series of commits so they can be 
             applied directly to the head node

そして、私たちは持っています

git-merge - Join two or more development histories together

これは良い説明です。

^{1.オリジナルで無修正}

個人的には、標準の作図手法があまり役に立たないと思います-矢印は常に私にとって間違った方向を指しているようです。（それらは一般的に、各コミットの「親」を指しており、最終的には逆方向になり、奇妙です）。

言葉で説明すると：

• ブランチをそのブランチにリベースするときは、ブランチをきれいにチェックアウトし、そこからすべての作業を行ったかのように見えるようにGitに指示します。これにより、誰かが確認できる変更のクリーンで概念的に単純なパッケージが作成されます。ブランチに新しい変更がある場合は、このプロセスを繰り返すことができます。ブランチの「先端」にある変更のクリーンなセットが常に得られます。
• ブランチにブランチをマージすると、この時点で2つのブランチ履歴が結合されます。後でさらに変更を加えてこれを行うと、履歴のインターリーブされたスレッドの作成を開始します。それらの変更の一部、私の変更の一部、一部の変更。一部の人々はこれが厄介または望ましくないと思います。

私が理解していない理由で、GitのGUIツールは、マージ履歴をよりきれいに提示し、個々のマージを抽象化するために、これまであまり努力をしていませんでした。したがって、「クリーンな履歴」が必要な場合は、リベースを使用する必要があります。

私はプログラマからの読み出しブログ記事持つ思い出すように見えるだけリベースなどに使用決してリベースを使用していないし。

例

これを簡単な例で説明してみましょう。プロジェクトの他のユーザーがユーザーインターフェースで作業していて、ドキュメントを書いているとします。リベースしないと、履歴は次のようになります。

Write tutorial
Merge remote-tracking branch 'origin/master' into fixdocs
Bigger buttons
Drop down list
Extend README
Merge remote-tracking branch 'origin/master' into fixdocs
Make window larger
Fix a mistake in howto.md

つまり、ドキュメントコミットの途中でのマージとUIコミットです。

コードをマージする代わりにマスターにリベースすると、次のようになります。

Write tutorial
Extend README
Fix a mistake in howto.md
Bigger buttons
Drop down list
Make window larger

すべてのコミットが一番上（最新）になり、残りのコミットが続きます masterブランチがます。

（免責事項：私は別の回答で言及されている「Gitについて嫌いな10のこと」の投稿の著者です）

受け入れられ、最も賛成された答えは素晴らしいですが、言葉だけで違いを説明しようとするとさらに役に立ちます。

マージ

• 「さて、私たちはリポジトリの2つの異なる開発状態を得ました。それらをマージしましょう。両親2人、子供1人。」

リベース

• 「メインブランチ（その名前に関係なく）の変更を機能ブランチに与えます。実際にメインブランチの現在の状態で、後で機能の作業を開始したふりをして、そうしてください。」
• 「それを反映するために私の変更の履歴を書き直してください。」（通常、バージョニングは特定の履歴を改ざんしないため、強制的にプッシュする必要があります）
• 「おそらく、私がレーキした変更が私の仕事とほとんど関係がない場合、コミットを差分ごとに見ると、履歴は実際にはあまり変化しません（「パッチ」と考えることもできます）。」

要約：可能な場合、リベースの方がほとんど常に優れています。メインブランチへの再統合を容易にします。

なぜなら？feature機能の作業は、メインブランチに関して1つの大きな「パッチファイル」（別名diff）として提示できます。複数の親を「説明」する必要はありません。少なくとも2つ、1つのマージからのものですが、存在する場合はさらに多くの可能性があります。いくつかのマージでした。マージとは異なり、複数のリベースは加算されません。（別の大きなプラス）

Gitリベースはマージに近いです。リベースの違いは次のとおりです。

• ローカルコミットは一時的にブランチから削除されます。
• git pullを実行する
• すべてのローカルコミットを再度挿入します。

つまり、すべてのリモートコミットの後で、すべてのローカルコミットが最後に移動されます。マージの競合がある場合は、それも解決する必要があります。

簡単に理解するために私の図を見ることができます。

Rebaseはコミットハッシュを変更するため、多くの競合を回避したい場合は、そのブランチが完了または安定したときにrebaseを使用します。

私はgit rebase vs mergeに関する非常に興味深い記事を見つけました、ここで共有することを考えました

• 履歴を完全に同じように表示したい場合は、マージを使用する必要があります。Mergeは履歴を保持しますが、リベースはそれを書き換えます。
• マージすると、履歴に新しいコミットが追加されます
• リベースは複雑な履歴を合理化する方が良いです。インタラクティブなリベースによりコミット履歴を変更できます。