多くのプロジェクトが「git merge」よりも「git rebase」を好むのはなぜですか？

DVCSを使用する利点の1つは、edit-commit-mergeワークフローです（多くの場合、CVCSによって施行されるedit-merge-commitを超える）。マージに関係なく、固有の各変更をリポジトリに記録できるようにすることで、DAGがプロジェクトの真の血統を正確に反映するようになります。

なぜこれほど多くのWebサイトが「マージコミットを回避する」ことについて話しているのですか？事前コミットまたはマージ後のリベースをマージすると、リグレッションの分離、過去の変更の取り消しなどが難しくなりませんか？

明確化のポイント： DVCSのデフォルトの動作があるコミットをマージ作成します。なぜそんなに多くの場所が、これらのマージコミットを隠す線形の開発履歴を見たいという願望について語っているのでしょうか？

ログをよりきれいにするため、マージコミットは避けたいと考えています。真剣に。彼らが育った一元化されたログのように見え、ローカルでは単一のブランチですべての開発を行うことができます。これらの美学以外の利点はありません。また、「中央」サーバーを経由せずに同僚から直接引き寄せることが競合しやすいなど、あなたが言及したものに加えていくつかの欠点があります。

2つの言葉で： git bisect

線形履歴により、バグの実際の原因を特定できます。

def bar(arg=None):
    pass

def foo():
    bar()

ブランチ1は、arg無効になったリファクタリングを実行します。

def bar():
    pass

def foo():
    bar()

ブランチ2には、使用する必要がある新しい機能がありますarg。

def bar(arg=None):
    pass

def foo():
    bar(arg=1)

マージの競合はありませんが、バグが導入されています。幸いなことに、この特定のものはコンパイルの段階でキャッチされますが、私たちは必ずしもそれほど幸運ではありません。バグがコンパイルエラーではなく予期しない動作として現れる場合、1〜2週間は見つからない可能性があります。その時点でgit bisect、救助に！

やばい。これは見たものです：

(master: green)
|             \_________________________
|                \                      \
(master: green)  (branch 1: green)     (branch 2: green)
|                 |                     |
|                 |                     |
(master/merge commit: green)            |
|                         ______________/
|                        /
(master/merge commit: red)
|
...days pass...
|
(master: red)

したがってgit bisect、ビルドを中断したコミットを見つけるために送信すると、マージコミットが特定されます。まあ、それは少し役立ちますが、それは本質的に単一のコミットではなく、コミットのパッケージを指しています。すべての祖先は緑です。一方、リベースでは、線形の履歴が得られます：

(master: green)
|
(master: green)
|
(all branch 1 commits: green)
|
(some branch 2 commits: green)
|
(branch 2 commit: red)
|
(remaining branch 2 commits: red)
|
...days pass...
|
(master: still red)

さて、git bisectビルドを壊した正確な機能のコミットを指し示すつもりです。理想的には、コミットメッセージは、別のリファクタリングを行ってすぐにバグを修正するのに十分な意図を説明します。

メンテナーがすべてのコードを作成しなかった場合、その効果は大規模プロジェクトでのみ悪化するため、特定のコミットが行われた理由/各ブランチの目的を必ずしも覚えていません。そのため、正確なコミットを正確に特定する（そして、その周りのコミットを調べることができる）ことは大きな助けになります。

とはいえ、私は（現在）まだマージを好んでいます。リリースブランチにリベースするとgit bisect、日々の作業の真の履歴を保持しながら、で使用する線形履歴が得られます。

要するに、マージは多くの場合、何かがうまくいかない別の場所であり、再度対処することを人々に非常に恐れさせるために一度だけ間違っていればよいからです（一度噛んだら2回は恥ずかしがります）。

そこで、新しいアカウント管理画面で作業しているとしましょう。新しいアカウントのワークフローでバグが発見されました。OK、2つの個別のパスを使用します-アカウント管理を終了し、新しいアカウントでバグを修正します。私たちは両方ともアカウントを扱っているため、非常によく似たコードを扱ってきました。おそらく、同じコードを調整する必要さえありました。

さて、現時点では、ソフトウェアの2つの異なるが完全に機能するバージョンがあります。私たちは両方とも、変更に対してコミットを実行し、コードを忠実にテストしました。そして、独立して、素晴らしい仕事をしたと確信しています。それで？

さて、マージする時が来ましたが......がらくた、今何が起こっていますか？2つのソフトウェアの作業セットから、アカウント管理が機能せず、新しいアカウントが破損し、古いバグがまだ存在するかどうかさえわからない、新しくバグの多いソフトウェアの統合された恐ろしい破損部分に非常にうまく行くことができます。

たぶん、ソフトウェアはスマートで、競合があると言って、ガイダンスを出すように主張したのかもしれません。さて、たわごと-私はそれをするために座って、あなたが私がすぐに理解しない複雑なコードを追加したのを見る 私が行った変更とは矛盾すると思います...私はあなたに尋ねます、そしてあなたが時間を得るとあなたがチェックし、あなたが理解していない私のコードを見ます。私たちのどちらかまたは両方は、座って適切なマージをハッシュし、場合によってはダング全体を再テストして、壊れていないことを確認する必要があります。

一方、他の8人は全員サディストのようにコードをコミットしています。マージの競合が発生する前に、いくつかの小さなバグ修正を行い、それらを提出しました。午後休み、会議などで立ち往生しています。たぶん私は休暇を取るべきです。または、キャリアを変えます。

そして、この悪夢から逃れるために、一部の人々はコミットメントを非常に恐れています（他に何が新しいのですか？）。このようなシナリオでは、自然にリスクを回避します-吸うと考えて、とにかくそれを台無しにしようとしない限り、その場合、人々は無謀な放棄で行動し始めます。はぁ

それであなたは行き​​ます。はい、現代のシステムはこの苦痛を緩和するように設計されており、簡単にバックアウトしてリベースおよびディベース、フリーベースおよびハングライドなどを行うことができるはずです。

しかし、それはすべての作業であり、フォークを見つける時間がある前に、電子レンジのボタンを押して4コースの食事を済ませたいだけで、すべてが非常に満たされていないように感じます-コードは仕事であり、生産的です意味がありますが、マージを適切に処理することは重要ではありません。

プログラマーは、原則として、優れた作業メモリを開発する必要があり、その後、問題を解決し、マージの競合を処理するとすぐに、そのジャンクと変数の名前とスコープをすべて忘れてしまいます。誤って処理されたマージ）は、死亡率を思い出させるための招待状です。

リベースは、変更をベースラインに戻すプロセスを簡素化する移動分岐点を提供します。これにより、長時間実行されているブランチをローカルの変更であるかのように扱うことができます。リベースせずに、ブランチはベースラインからの変更を蓄積し、ベースラインにマージされる変更に含まれます。

マージすると、ベースラインは元の分岐点に残ります。分岐した行から数週間分の変更をマージすると、分岐点から多くの変更があり、その多くがベースラインに含まれます。これにより、ブランチでの変更を特定することが難しくなります。変更をベースラインに戻すと、変更とは無関係の競合が発生する場合があります。競合の場合、一貫性のない変更をプッシュすることができます。進行中のマージは管理に手間がかかり、変更を緩めるのは比較的簡単です。

Rebaseは、分岐点をベースラインの最新リビジョンに移動します。衝突が発生した場合は、変更のみが原因となります。変更のプッシュははるかに簡単です。競合は、追加のリベースを行うことでローカルブランチで処理されます。競合するプッシュの場合、変更をプッシュする最後のプッシュは、変更に関する問題を解決する必要があります。

自動化ツールは、マージコードのコンパイルと実行を確実にすることで改善されており、構文の競合を回避していますが、マージによって生じる可能性のある論理的な競合がないことを保証できません。したがって、「成功した」マージは、実際には何も保証しない場合に、あなたに誤った自信の感覚を与えます。そして、すべてのテストをやり直さなければなりません。

私が見るように、分岐とマージの本当の問題は、それがことわざを追い払うことです。1週間「自分の小さな世界で仕事をする」と言って、後で発生する問題に対処できます。ただし、バグの修正は、新しい場合は常に高速/安価です。すべてのコードブランチがマージされ始める頃には、すでに行われた作業のニュアンスの一部を忘れているかもしれません。

上記の2つの問題をまとめると、アクティブな開発が少し遅くなったとしても、同じトランクで作業をし、競合が発生するたびに継続的に解決する方が簡単で簡単な状況に陥ることがあります。

追加の関連ポイントは次のとおりです。リベースすると、リリースブランチの機能を簡単に選択または元に戻すことができます。

いずれの回答でも次の3つのことは言われていません。

• ブランチ内での違い：

  • マージコミットがある場合、ブランチ内の任意のコミットペアを区別することは非常に困難になります。

• 一度に1つのアイテムをマージする：

  • 2つのブランチの違いを解決する場合、通常、マージは一度にすべて発生し、マージの競合は、特定のコミットが競合の原因となったコンテキストなしで行う必要があります。リベースすると、競合が発生した時点でリベースが停止し、そのコンテキストで解決できます。

• プッシュ前のクリーンアップ：

  • 後で修正する必要があるコミットを間違えた場合、インタラクティブリベースをプッシュしていない場合は、コミットを結合/分割/変更/移動できます。マージした場合でもそれを行うことができますが、マージ境界を越えて結合/分割/変更/移動したい場合は非常に困難になります。