ブランチとブランチ ポリシーについて

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

ブランチ ポリシーは、Git ワークフローの重要な部分であり、以下を可能にします。

  • 進行中の作業を、メイン ブランチの完了した作業から分離する
  • 変更がメインに到達する前にビルドされることを保証する
  • 特定のブランチに投稿できるユーザーを制限する
  • ブランチを作成できるユーザーとブランチの名前付けガイドラインを適用する
  • コード変更ごとに適切なレビュー担当者を自動的に含める
  • 必要なコード レビュー担当者にベスト プラクティスを強制する

次の表は、ブランチをカスタマイズするために定義できるポリシーをまとめたものです。 すべてのリポジトリおよびブランチのポリシーと設定の概要については、Git リポジトリの設定とポリシーに関するページを参照してください。

ポリシー

[Default]

説明

レビュー担当者の最少数が必要です

オフ

pull request 時に、指定した人数のレビュー担当者からの承認を必須とします。

リンクされた作業項目を確認します

オフ

pull request 時に、リンクされた作業項目を確認して、追跡可能性を強化します。

コメント解決の有無を確認する

オフ

pull request 時に、すべてのコメントが解決したことを確認します。

マージの種類を制限する

オフ

pull request が完了した際に使用できるマージの種類を制限して、ブランチ履歴を制御します。

Add Build Validation policies (ビルド検証ポリシーを追加する)

オフ

1 つ以上のポリシーを追加して、pull request の変更を事前にマージしてビルドすることでコードを検証します。 ポリシーを有効または無効にすることもできます。

Add Status Check policies (状態の確認ポリシーを追加する)

オフ

1 つ以上のポリシーを追加して、pull request を完了するために、他のサービスが成功状態を投稿することを必須とします。 ポリシーを有効または無効にすることもできます。

自動的に追加されるレビュー担当者

オフ

1 つ以上のポリシーを追加して、pull request がコードの特定の領域を変更するときに、コード レビュー担当者が自動的に追加されるように指定します。 ポリシーを有効または無効にすることもできます。

Git ブランチ戦略を採用する

リポジトリには、チームが常に良好な状態であることに頼っている重要なブランチがいくつかあります (main ブランチなど)。

これらのブランチに対して何らかの変更を行うには pull request が必要です。 開発者が保護されているブランチに直接変更をプッシュすると、そのプッシュは拒否されます。

次の 3 つの概念から戦略をビルドすることで、ブランチ戦略をシンプルに保ちます。

  1. すべての新機能とバグの修正には、機能ブランチを使用します。
  2. pull request を使用して機能ブランチをメイン ブランチにマージします。
  3. メイン ブランチを高品質で最新の状態に維持します。

これらの概念を拡張し、矛盾を回避する戦略により、チームのバージョン管理ワークフローが一貫し、実行しやすくなります。

ブランチで作業を作成する

Git ブランチは、正確なコミットの履歴を保持する小さな参照に過ぎないので、作成が安価です。

ブランチに変更をコミットしても、他のブランチには影響しません。 変更をメイン プロジェクトにマージしなくても、ブランチを他のユーザーと共有できます。

新しいブランチを作成して、機能の変更やバグ修正をメイン ブランチやその他の作業から分離することができます。

ブランチは軽量であるため、ブランチ間の切り替えはすばやく簡単です。 Git は、ブランチを操作するときにソースの複数のコピーを作成するのではなく、コミットに保存されている履歴情報を使用して、ブランチでの作業を開始するときにファイルを再作成します。

Git ワークフローでは、機能とバグ修正を管理するためのブランチを作成して使用する必要があります。

コードの共有や pull request を使用したコードのレビューなど、Git ワークフローの残りの部分は、すべてブランチを介して機能します。

ブランチ内の作業を分離すると、現在のブランチを変更することで、作業内容を簡単に変更できます。

Git ブランチはどのように作成されますか?

ブランチは、branch コマンドを使用して作成します。 Branch は、Git に新しいブランチの参照と親コミットへのポインターを作成します。そうすることで、ブランチにコミットを追加するときに Git が変更履歴を保持できるようにします。

他のユーザーが共有したブランチを使用している場合、Git は上流の追跡関係を維持します。 リレーションシップは、ローカル リポジトリのブランチをリモート リポジトリの対応するブランチに関連付けます。

上流追跡を使用すると、プッシュとプルを使用して変更を他のユーザーと簡単に同期できます。

Git のメインから離れたブランチのビジュアル

このスクリーンショットでは、メイン ブランチから作成された新しいブランチを確認できます。 両方のブランチで作業を続行すると、コミットが両方のブランチに追加されます。

Git は常に、現在のローカル ブランチに新しいコミットを追加します。 コミットする前に作業しているブランチを確認して、間違ったブランチに変更をコミットしないようにします。

checkout コマンドを使用してローカル ブランチ間を入れ替えます。 Git では、チェックアウトしたブランチの最新のコミットと一致するように、コンピューター上のファイルが変更されます。

ブランチ内の作業をチームの他のユーザーと共有する準備ができたら、変更をプッシュしてリモート ブランチを更新します。

よくある間違いは、いくつかの変更を加えて commit を実施した後に、間違ったブランチにいることに気づいて、正しいブランチに checkout を実施することです。

各ブランチには独自のバージョンのコードがあるため、最新の変更はファイル システム上にはありません。

Git は、変更を行った前のブランチではなく、入れ替え先のブランチの最後のコミットにファイルの状態を戻します。

ブランチからコミットをチェリーピックするか、変更を正しいブランチにマージする必要があります。

ブランチを使用して開発を管理する

Git は、作業中のブランチを追跡し、ブランチに checkout を実施するときに、ファイルがそのブランチでの最新のコミットと一致することを確認します。

ブランチを使用すると、同じローカル Git リポジトリ内の複数のバージョンのソース コードを同時に操作できます。

checkout で作業するブランチを Git に指示することで、Git ではそのブランチに適したファイル・バージョンに設定されます。

ブランチを使用して作業を分離する場合、システムに複数のリポジトリは必要ありません。

複製後に開発環境を 1 回設定します。 次に、Git ブランチを使用して、機能作業とバグ修正を入れ替えます。

ブランチに関する方法ガイド

ブランチを操作する場合の一般的なタスクを完了する方法について説明します。