git - リベースと、プッシュされたコミットをリベースすることの意味

Question

すでにプッシュしたコミットをリベースすべきではないとよく言われます。その意味は何ですか？

Answer 1

これを理解するには、git の仕組みについて少し理解する必要があります。git リポジトリはツリー構造であり、ツリーのノードはコミットです。非常に単純なリポジトリの例を次に示します。

master ブランチには 4 つのコミットがあり、各コミットには ID (この場合は a、b、c、および d) があります。d は現在、マスター ブランチの最新のコミット (または HEAD) であることがわかります。

ここには、master と my-branch の 2 つのブランチがあります。master と my-branch の両方にコミット a と b が含まれていることがわかりますが、その後分岐し始めます。master には c と d が含まれ、my-branch には e と f が含まれます。b は、master と比較して my-branch の「マージ ベース」であると言われています。より一般的には、単なる「ベース」です。これは理にかなっています: my-branch が以前のバージョンの master に基づいていることがわかります。

たとえば、my-branch が古くなり、master の最新バージョンで更新したいとします。別の言い方をすれば、my-branch には c と d が含まれている必要があります。マージを行うこともできますが、そうするとブランチに奇妙なマージ コミットが含まれてしまい、プル リクエストのレビューがはるかに難しくなります。代わりに、リベースを実行できます。

リベースすると、git はブランチのベース (この場合は b) を見つけ、そのベースと HEAD (この場合は e と f) の間のすべてのコミットを見つけ、ブランチの HEAD でそれらのコミットを再生します。 (この場合はマスター) にリベースしています。Git は実際に、マスター上で変更がどのように見えるかを表す新しいコミットを作成します。図では、これらのコミットは e' および f' と呼ばれます。Git は以前のコミットを消去しません。e と f はそのまま残され、リベースで問題が発生した場合は、元の状態にすぐに戻ることができます。

多くの異なる人々がプロジェクトでシミュレートして作業している場合、プル リクエストはすぐに古くなる可能性があります。「古い」プル リクエストとは、開発のメイン ラインに対応していないものであり、プロジェクトにマージする前に更新する必要があります。プル リクエストが古くなる最も一般的な理由は競合によるものです。2 つのプル リクエストの両方が同じファイル内の類似した行を変更し、1 つのプル リクエストがマージされると、マージされていないプル リクエストに競合が発生します。場合によっては、プル リクエストが競合せずに古くなることがあります。おそらく、コードベース内の別のファイルの変更により、新しいアーキテクチャに準拠するためにプル リクエスト内の対応する変更が必要になるか、誰かが失敗したユニット テストを誤ってマスターブランチ。理由はともかく、

Answer 2

The ProGit book has a good explanation.

The specific answer to your question can be found in the section titled "The Perils of Rebasing". A quote from that section:

When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.

Update:
Based on your comment below, it sounds like your are having difficulty with your Git workflow. Here are some references that may help:

• The gitworkflows man page: See "Merging Upwards" and "Topic Branches"
• ProGit: See "Private Managed Team"
• Jarrod Spillers blog: See "git merge vs git rebase: Avoiding Rebase Hell"

Answer 3

リベースは履歴を書き換えます。誰もその歴史を知らないのなら、それでいいのです。ただし、その履歴が公に知られている場合、Git での履歴の書き換えは、現実の世界と同じように機能します。陰謀が必要です。

コンスピラシーをまとめるのは非常に難しいため、最初からパブリック ブランチのリベースは避けたほうがよいでしょう。

成功した陰謀の例があることに注意してください: Junio C. puHamano の git リポジトリ (Git SCM の公式リポジトリ) のブランチは頻繁にリベースされています。これが機能する方法は、使用するほとんどすべての人がpuGit 開発者メーリングリストにも登録していることです。puブランチがリベースされているという事実は、メーリングリストと Git Web サイトで広く公開されています。

Answer 4

リベースは、リポジトリの履歴を変更します。コミットを世界にプッシュした場合、つまり他の人が利用できるようにした後で、コミット履歴の見方を変えると、古い履歴を持つ人と一緒に作業することが難しくなります。

有害と見なされるリベースは良い概要だと思います。