GitHub でホストされているプロジェクトがあります。GitHub にプッシュされたメタモデルという名前の共有トピック ブランチで新しい機能セットを開発しています。同時に、マスターで進行中のバグ修正作業が進行中です。計画は、最終的にメタモデルを master に統合し直し、その時点でメタモデル ブランチがなくなることです。これらのブランチには両方とも、1 つのディレクトリにマージする内容の 2 つのディレクトリが含まれています。この時点で、2 つのディレクトリは 2 つのブランチ間ですでに分岐しています。さらに、支店統合まではさらに分岐していきます。
各ブランチで 2 つのディレクトリを個別にマージした場合、ブランチを統合するとどうなりますか? プロジェクトとして、ここで関係がある場合に備えて、リベースによってブランチを統合することを選択しました。
Git は、ディレクトリやファイル名さえ気にしません。内容重視です。また、マージについてはかなりインテリジェントです (物事が単純に移動または名前変更されたときを把握します)。
したがって、基本的に、「これらのブランチを統合するとどうなるか」という質問に対する答えは、「わかりません」です。内容は見ていません。しかし、Git はコンテンツの相違点と類似点をかなり効率的に比較し、すべてをうまく組み合わせることはできます。Git が動かなくなったものはすべて、マージの競合として表示され、ケースバイケースで解決する必要があります。
この状況では、Git の履歴と変更がかなり複雑になり始めていることを考えると、リベースには注意が必要です。リベースはうまくいくかもしれませんが、面倒になった場合に備えてロールバックする準備ができています.
あなたのブランチは大きく分岐しており、異なるルートやパスに移動しているため、それらを元に戻すために直接マージを行う方がよい場合があります。そうすれば、有害な/回復不可能な方法で履歴を書き換えるリスクがなくなります (リベースは履歴を書き換える形式であることを忘れないでください)。さらに、Git を直接マージすると、すべてが組み合わされた新しいコミットが生成されます。これは、ロールバックが必要な場合に備えて、(発生した劇的な違いを考慮すると) 貴重な「分岐点」コミットになる可能性があります。 .
リベースは履歴をクリーンアップするので便利ですが、このような複雑な状況では絶対にやりません。
基本的に、ブランチをリモートにプッシュしたことがある場合、ほとんどの場合、そのブランチでのリベースの使用を避けたいと思うでしょう。ブランチのローカルでいくつかの変更を行って履歴を改善するのは良いことですが、その後、リモートにプッシュする場合はマージを使用してください。
マージと競合のクリーンアップに集中します。