Git の学習: git merge コマンドを理解する

この記事は、Git ブランチについて学習し、ブランチを使用するための Git Merge コマンドを紹介するのに役立ちます。

Git では、マージはフォークされたコミット履歴を元に戻す方法です。 git merge コマンドは、以前に git Branch コマンドを使用して作成したブランチと、このブランチ上で個別に開発されたコンテンツを 1 つのブランチに統合するために使用されます。

以下のすべてのコマンドは、他のブランチを現在の作業ブランチにマージすることに注意してください。現在の作業ブランチの内容はマージ操作により更新されますが、ターゲット ブランチはまったく影響を受けません。繰り返しますが、これは、git merge が通常、現在の作業ブランチを選択するための git checkout コマンドの使用や、git ブランチの使用など、他のいくつかの git コマンドと組み合わせて使用​​されることを意味します。 dマージされた放棄されたブランチを削除するコマンド。

仕組み

git merge は、複数のコミット シーケンスを統合されたコミット履歴にマージします。最も一般的な使用シナリオでは、git merge を使用して 2 つのブランチをマージします。このドキュメントの残りの部分では、このマージ シナリオに焦点を当てます。このシナリオでは、git merge は 2 つのコミット ポインター (通常は 2 つのブランチの先頭のコミット) を受け入れ、2 つのブランチの最新の共通コミットまで前方トレースします。この共通のコミットが見つかると、Git は両方のブランチのそれぞれのコミット シーケンスをマージする新しい「マージ コミット」を作成します。

たとえば、main ブランチから派生した機能ブランチがあり、この機能ブランチを main ブランチにマージして戻したいと考えています。

マージ コマンドを実行すると、指定されたブランチが現在の作業ブランチにマージされます。現在の作業ブランチは main であると仮定します。 Git は、2 つのブランチに基づいてコミットをマージするための独自のアルゴリズムを決定します (詳細は以下で説明します)。

マージ コミットには 2 つの親コミットがあるため、マージ コミットは通常のコミットとは異なります。マージ コミットを作成すると、Git は 2 つの別々のコミット履歴を 1 つに自動的にマージしようとします。ただし、Git は、特定のデータに両側のコミット履歴の変更が含まれていることを検出した場合、それを自動的にマージすることはできません。この状況はバージョン競合と呼ばれますが、現時点では、Git はマージを続行するために手動介入を必要とします。

マージの準備

実際のマージ操作の前に、マージ プロセスがスムーズに進むようにいくつかの準備手順を実行する必要があります。

マージを受け取るブランチを確認する

git status コマンドを実行して現在のブランチのステータスを確認し、HEAD であることを確認します。マージ ブランチを受け取る正しいブランチを指します。そうでない場合は、git checkout コマンドを実行して、正しいブランチに切り替えます。この例では、git checkout main を実行します。

最新のリモート コミットを取得する

マージ操作に関与する両方のブランチがリモート ウェアハウスの最新ステータスに更新されていることを確認します。 git fetch を実行して、リモート ウェアハウスから最新のコミットをプルします。フェッチ操作が完了したら、main ブランチがリモート ブランチと同期していることを確認するために、git pull コマンドを実行する必要があります。

合併

上記の準備が完了すると、正式に合併を開始できます。 git merge <branch></branch> コマンドを実行します。ここで、 は現在のブランチにマージする必要があるターゲット ブランチの名前です。

早送りマージ

現在の作業ブランチとマージ先ブランチ間の送信履歴が直線パスの場合、早送りマージを実行できます。この場合、実際に 2 つのブランチをマージする必要はなく、Git は現在のブランチの先頭ポインタをターゲット ブランチの先頭に移動 (つまり、早送り) するだけで済みます。この場合、早送りマージによってコミット履歴が 1 か所にマージされ、ターゲット ブランチのコミットが現在のブランチのコミット履歴に含まれるようになります。関数ブランチを main ブランチに早送りマージするプロセスについては、次の図を参照してください。

ただし、早送りマージは 2 つのブランチが分割されるときに発生しますが、クロスの場合は実行できません。現在のブランチに対するターゲット ブランチのコミット履歴が線形でない場合、Git は 3 方向マージ アルゴリズムを通じて 2 つのブランチをマージする方法しか決定できません。 3 方向マージ アルゴリズムでは、両側のコミット履歴を統合するために専用のコミットを使用する必要があります。この用語は、Git がマージ コミットを生成するには、2 つのブランチの最上位コミットとそれらの共通の祖先コミットの 3 つのコミットを使用する必要があるという事実に由来しています。

実際にはこれらのさまざまなマージ戦略を使用することを選択できますが、ほとんどの開発者は、特に小規模な機能の開発やバグ修正の場合、(rebasing コマンドを使用する) 早送りマージを好みます。長期的な開発機能ブランチをマージする場合は、3 方向マージ方法の方が適しています。 2 番目のシナリオでは、マージによって生成されたマージ コミットは、2 つのブランチのマージのマークとしてコミット履歴に保持されます。

次に、以下の最初の例を使用して、早送りマージを実行する方法を示します。次のコマンドは、まず新しいブランチを作成し、新しいブランチ上で 2 つのコミットを作成し、次に早送りマージを使用して新しいブランチを main ブランチにマージします。

# Start a new feature
git checkout -b new-feature main
# Edit some files
git add <file>
git commit -m "Start a feature"
# Edit some files
git add <file>
git commit -m "Finish a feature"
# Merge in the new-feature branch
git checkout main
git merge new-feature
git branch -d new-feature

この例のワークフローは通常、短期的な機能開発に使用されます。この開発プロセスは比較的独立した開発プロセスとみなされ、それに応じて調整と管理が必要な長期的な開発プロセスです。 . 機能開発ブランチ。

また、この例では、new-feature のコンテンツがメイン ブランチにマージされているため、Git は git Branch -d コマンドに対して警告を発行しないことにも注意してください。

場合によっては、ターゲット ブランチのコミット履歴は現在のブランチに対して線形であり、早送りマージできますが、この時点でマージが行われたことをマークするマージ コミットが必要な場合もあります。 git merge コマンドを実行するときに、--no-ff オプションを使用できます。

git merge --no-ff <branch>

上記のコマンドは、指定されたブランチを現在のブランチにマージしますが、常にマージ コミットを生成します (このマージ操作が早送りできる場合でも)。このコマンドは、リポジトリのコミット履歴でマージ イベントをマークする必要がある場合に便利です。

3 方向マージ

次の例は上記と似ていますが、機能ブランチが進むにつれて main ブランチ自体も変更されるため、3 方向のマージが行われます。マージする場合は -way merge が必要です。このシナリオは、大規模な機能開発を実行する場合、または複数の開発者が同時に開発を行う場合に非常に一般的です。

Start a new feature
git checkout -b new-feature main
# Edit some files
git add <file>
git commit -m "Start a feature"
# Edit some files
git add <file>
git commit -m "Finish a feature"
# Develop the main branch
git checkout main
# Edit some files
git add <file>
git commit -m "Make some super-stable changes to main"
# Merge in the new-feature branch
git merge new-feature
git branch -d new-feature

この場合、main の先頭ポインタを new-feature## に直接移動する方法がないため、Git は早送りを実行できないことに注意してください。 # ブランチをマージします。

実際の作業シナリオでは、

新機能は非常に大きな機能であるはずであり、開発プロセスは長時間にわたるため、必然的に 新しい機能もありますmain ブランチにコミットします。 feature ブランチのサイズが上記の例のように小さい場合は、リベースを使用して new-feature ブランチを main ブランチにリベースしてから、早送りマージを実行できます。これにより、プロジェクトのコミット履歴に過剰な冗長性が生じることも避けられます。

競合の解決

マージされる 2 つのブランチが同じファイルの同じ部分を変更した場合、Git はコンテンツのどのバージョンを使用するかを判断できません。この問題が発生すると、マージ コミットがコミットされる前にマージ プロセスが停止され、ユーザーがこれらの競合を手動で修正する機会が与えられます。

Git のマージ プロセスの優れた点は、よく知られた編集/ステージング/コミット ワークフローを使用して競合を解決することです。マージ競合が発生した場合、

git status コマンドを実行すると、どのファイルに競合が含まれており、手動で解決する必要があるかがリストされます。たとえば、両方のブランチが hello.py ファイルの同じ部分を変更すると、次のような情報が表示されます。

On branch main
Unmerged paths:
(use "git add/rm ..." as appropriate to mark resolution)
both modified: hello.py

競合の表示方法

When Git はマージ プロセス中に競合に遭遇すると、影響を受けるファイル内の関連コンテンツを編集し、競合のこの部分の異なるコンテンツを示す視覚的なマーカーを追加します。これらの視覚的マーカーは次のとおりです: <<<<<<<<,=======,>>>>>>>。競合が発生した特定の場所を見つけるには、ファイル内でこれらの視覚マーカーを検索するのが簡単です。

here is some content not affected by the conflict
<<<<<<< main
this is conflicted text from main
=======
this is conflicted text from feature branch
>>>>>>> feature branch;

一般的に、====== マークの前のコンテンツはマージを受け取るブランチから取得され、その後のコンテンツはマージされるブランチから取得されます。

競合する部分が見つかったら、必要に応じて競合を修正できます。競合の修復が完了し、マージを続行する準備ができたら、

git add コマンドを実行して、競合が解決されたファイルをステージング領域に追加し、これらの競合が解決されたことを Git に伝えるだけです。この後、通常のコード送信と同様に git commit を実行してマージコミットを完了します。このプロセスは、通常の状況でコードを送信するのとまったく同じです。つまり、競合の処理は一般の開発者にとって簡単なことです。

また、マージ競合は 3 者間マージ中にのみ発生する可能性があり、早送りマージ中には競合が発生しないことにも注意してください。

概要

この記事は、git merge コマンドの概要です。 Git を使用するプロセスにおいて、マージは非常に重要な操作です。この記事では、マージ操作の背後にある仕組みと、早送りマージと 3 方向マージの違いについて説明します。読者が覚えておく必要がある重要なポイントは次のとおりです。

• #Git マージ プロセスは、さまざまなコミット シーケンスを統合されたコミット履歴にマージすることです

# #Git マージ プロセスには、早送りマージと 3 方向マージという 2 つの主な方法があります。
2 つのコミット シーケンスに競合がない限り、Git は通常、コミットをマージできます。自動的に
推奨学習: 「

Git チュートリアル

」

以上がGit の学習: git merge コマンドを理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。