次の方法で共有


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

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

ブランチ ポリシーは Git ワークフローの重要な部分であり、次の操作を行うことができます。

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

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

Policy

デフォルト

説明


Off

プル要求に対して、指定した数のレビュー担当者からの承認を要求します。

Off

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

Off

プル要求ですべてのコメントが解決されていることを確認します。

Off

プル要求の完了時に使用可能な種類のマージを制限して、ブランチ履歴を制御します。

Off

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

Off

1 つ以上のポリシーを追加して、他のサービスが正常な状態を投稿してプル要求を完了するように要求します。 ポリシーを有効または無効にすることもできます。

Off

プル要求がコードの特定の領域を変更したときに自動的に含めるコード レビュー担当者を指定する 1 つ以上のポリシーを追加します。 ポリシーを有効または無効にすることもできます。

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

リポジトリには、チームが常に適切な状態にあることに依存する重要なブランチがいくつかあります ( main ブランチなど)。

これらのブランチに変更を加えるために pull request を要求する。 保護されたブランチに変更を直接プッシュする開発者は、プッシュが拒否されます。

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

  1. すべての新機能とバグ修正に機能ブランチを使用します。
  2. プル要求を使用して、機能ブランチをメイン ブランチにマージします。
  3. 高品質の up-to-date メイン ブランチを維持します。

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

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

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 ブランチを使用して、機能の作業とバグ修正をスワップします。

ガイドの分岐方法

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