変更をブランチおよびマージする

6 分

Bicep コードを操作する場合、一度に複数のことを実行する必要があることはよくあります。たとえば、おもちゃ会社の Web サイトに取り組んでいる場合の 2 つのシナリオを次に示します。

Web サイトの開発チームは、大量の変更による Bicep ファイルの更新で、あなたの援助を求めています。ただし、チームはこれらの変更をまだライブにしたくありません。新しいバージョンの作業と並行して、Web サイトの現在のライブバージョンに対して微調整を行うことができる必要があります。
Web サイトのパフォーマンスの向上に役立つと思われる試験的な変更に取り組んでいます。ただし、これらの変更は暫定的です。準備が整うまで、ライブバージョンの Web サイトには適用したくありません。

このユニットでは、Git ブランチについて説明します。

注意

このユニットのコマンドは、概念を説明するために示されています。コマンドはまだ実行しないでください。ここで学習した内容をすぐに練習します。

ブランチとは

ブランチによって、ファイルの複数のアクティブなコピーを作成する方法が提供されます。必要なときにいつでもブランチを作成して切り替えることができます。ブランチによる作業が完了したら、それを別のブランチにマージできます。または、削除することもできます。これにより、すべての変更が削除されます。

すべての作業にブランチを使用するのが一般的です。多くの場合、1 つのブランチをファイルの既知の正常なバージョンまたはライブバージョンを表すプライマリブランチとして指定します。慣例により、このブランチは通常、main と呼ばれます。任意の数の他のブランチを作成できます。ブランチに対する変更の準備ができたら、ブランチを main ブランチにマージします。

ブランチを作成してチェックアウトする

Git でのブランチの作成はすばやく簡単です。これを行うにはいくつかの方法がありますが、最も簡単な方法は、一般に git checkout コマンドを使用することです。次は、my-experimental-changes という名前の新しいブランチを作成する方法の例です。

git checkout -b my-experimental-changes

このコマンドでは、実際に 2 つのことを行います。my-experimental-changes ブランチを作成し、新しく作成されたブランチをチェックアウトします。 チェックアウトとは、フォルダーに表示されるファイルのコピーに、ブランチの内容が反映されることを意味します。異なる変更セットを含む 2 つのブランチがある場合、一方のブランチをチェックアウトしてから、他方のブランチをチェックアウトすることにより、2 つの変更セット間で切り替えることができます。

git checkout コマンドを使用して、既存のブランチに切り替えることもできます。この例では、main ブランチをチェックアウトします。

git checkout main

Note

通常は、別のブランチをチェックアウトする前に、変更をコミットする必要があります。チェックアウトできない場合は、Git から警告されます。

ブランチの操作

ブランチに切り替えたら、通常と同じようにファイルをコミットします。実際、これまでに行ってきたことはすべて、ブランチに対するものでした。 main ブランチを操作していましたが、これは、新しいリポジトリを作成したときの既定のブランチです。

ブランチをチェックアウトしている間にいくつかの変更をコミットすると、そのコミットはそのブランチに関連付けられます。別のブランチに切り替えると、ブランチをマージするまで、git log 履歴にコミットが表示されない可能性があります。

ブランチをマージする

ブランチは、Bicep コードの現在のライブバージョンから、進行中の作業を分離するための優れた方法です。ただし、ブランチ上のファイルへの変更が完了したら、多くの場合に、変更を main ブランチにマージしたいと考えます。

1 つのブランチを操作している場合に、別のブランチの変更を現在のブランチにマージするには、git merge コマンドを使用します。

Note

マージする前に、マージ先ブランチ (多くの場合、target ブランチと呼ばれます) をチェックアウトしてください。別のブランチから現在の作業ブランチにマージしていることに注意してください。

次は、main ブランチをチェックアウトし、次に変更を my-experimental-changes ブランチから main ブランチにマージする方法を示した例です。最後に、my-experimental-changes ブランチは必要なくなったため、削除します。

git checkout main
git merge my-experimental-changes
git branch -d my-experimental-changes

ヒント

他のユーザーと協力する場合は、ブランチを直接マージするのではなく、pull request を使用して変更をマージするのが一般的です。コラボレーションと pull request の詳細について手短に説明します。

マージ競合

Git で 1 つのブランチから別のブランチに変更がマージされるときに、変更されたファイルが調べられ、変更をまとめてマージしようと試みられます。場合によっては、2 つの異なるブランチで同じコード行を変更していることがあります。このような状況では、Git によって正しいバージョンのコードを選択できないため、代わりに merge conflict が生成されます。

このモジュールでは、マージ競合については詳しく説明しませんが、マージ競合が発生する可能性があることを知っておくことは重要です。他のユーザーと共同作業する場合、発生する頻度が上がります。このモジュールの概要で、Git と Visual Studio Code がマージ競合の解決にどのように役立つかに関する詳細情報へのリンクを提供しています。

Git ワークフロー

このモジュールでは、ブランチの基本についてのみ説明しています。しかしながら、ブランチは強力であり、柔軟に作業できます。たとえば、他のブランチからブランチを作成し、ブランチを他の任意のブランチとマージできます。ブランチを使用すると、自分とチームが作業したい方法をサポートするあらゆる種類のワークフローを作成できます。

このモジュールでは、trunk-based development と呼ばれる単純なワークフローを使用します。このワークフローでは、1 つの trunk ブランチがあります。たとえば、この記事の例では main を使用します。そのブランチは、コードの既知の正常なバージョンを表します。変更または作業を行うときに、このトランクからブランチを作成します。

トランクベースの開発では、トランクブランチに直接変更を加えることは推奨されていません。他のブランチは短時間のみ保持するように努めます。これにより、マージ競合を最小限に抑えることができます。さらに、作業の部分が完了するたびにそれらのブランチをマージおよび削除します。

チーム環境でよく起こるワークフローは他にもあります。変更のリリース頻度を調整した方が良いこともあります。このモジュールの概要で、Git ワークフローに関する詳細情報へのリンクを提供しています。