別の開発者によって分岐されたマスター ブランチがあり、機能を追加しました。それまでの間、同じファイルのいくつかに変更を加えました。行に直接の競合はありませんが、競合を最小限に抑えて、他のブランチをマスターにマージするために使用するさまざまな方法について疑問に思っています。
アスキー アートの視覚化:
A-B-C-D
\
1-2-3
コミット A をチェックアウトし、3 でブランチをマージしてから、B から D までの変更を再適用するのが最善でしょうか? または、3 を D にマージする必要がありますか? または、私が見逃しているより良い方法があると確信しています。
私はgitにかなり慣れていませんが、コツをつかんでいると思いますが、正しく使用していることを確認したいだけです。
ABCD の元のブランチ名が「orig」であるとします。そして、ブランチ名が「master」の「3」にいます。これを試して：
git rebase orig
をチェックアウトし、 –<code>3Aでマージしてから–<code>D を適用するという説明は、リベースと呼ばれる標準的な Git 手法です。自動的に解決できない競合がないと仮定すると、次の 1 つのコマンドで解決できます。1B
git rebase --onto {commit 3} {commit A} {commit D}
リベースの実行中に競合が発生した場合、Git はそれらを解決する方法について説明します。
ただし、通常の Git ワークフローでは、ブランチをマージするだけです。何らかの理由がない限り、マージを行うことをお勧めします。
マージは開発プロセスをより正確に反映します。これは、履歴を見て、機能がどのように開発され、メイン コードにマージされたかを正確に確認できることを意味します。リベースすると、履歴が人為的にきれいに見えます。便利な場合もありますが、物事がどのように行われたかを隠してしまいます。