ドキュメントの検索
karat

+

K

APIリファレンス ↗
データ統合Code Repositoriesリポジトリの管理ブランチ設定
Feedback

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

ブランチ設定

このページでは、Code Repositories のさまざまなブランチ設定について説明します。

デフォルトブランチ

複数のブランチがある Code Repositories では、デフォルトブランチをベースブランチとして設定できます。デフォルトでは、すべてのプルリクエストとコミットがそのブランチに対して行われます(他のブランチを選択しない限り)。通常、デフォルトブランチは master ブランチです。

Code Repository のメインブランチは、Settings > Branches > Default branch に移動して選択できます。

マージモード

プルリクエストで提案されたコード変更をマージするためのいくつかの戦略があります。Settings タブでは、プルリクエストページのコード作者に利用できるマージモードを1つ以上選択できます。

  • Squash and merge - Squash and merge モードでは、プルリクエストが導入するすべての変更を取り込んだ単一のコミットをターゲットブランチに作成します。これにより、デフォルトブランチのコミット履歴がよりコンパクトになります。
  • マージ - プルリクエストで マージ を使用すると、ブランチで作成されたすべての個別のコミットが、マージコミットとともにターゲットブランチに追加されます。ターゲットブランチのコミット履歴では、すべての個別のコミットが元のタイムスタンプで表示されます。これは、開発ブランチで作成された時刻を示しています。
  • Fast-forward でマージ - ターゲットブランチからブランチへの直接パスがある場合(ターゲットブランチに追加の変更がない場合)、Fast-forward でマージは、ターゲットブランチを開発ブランチの先頭に進め、コミット履歴を結合します。

選択したすべてのマージモードは、プルリクエストページにオプションとして表示されます。Squash and merge モードが選択されている場合、その他の選択されたモードはメニューで利用できるようになります。

保護されたブランチ

同じコードリポジトリに複数の作者が寄稿している場合や、リポジトリが重要なデータアセットをバックアップしている場合、ブランチを保護して、意図しない変更に対するガバナンスと防御のレベルを高めることができます。保護されたブランチは、プルリクエストを介してのみ変更でき、事前に定義された一連の要件を満たす必要があります。

デフォルトでは、コードリポジトリの所有者のみがブランチ保護設定を変更でき、所有者とエディターの両方が保護されたブランチにプルリクエストをマージできます。アクセス権に関係なく、すべてのコード作者は保護されたブランチポリシーに従う必要があります。

ブランチ設定パネルで以下の要件を設定できます。

ci/foundry-publish が正常に実行されることが必要

データへの変更を公開するには、継続的インテグレーションプロセス ci/foundry-publish が実行され、正常に終了する必要があります。正常に終了する前に変更をマージすると、変更が有効になる保証はありませんので、保護されたブランチに対してこれを要件とすることを強くお勧めします。

コードレビューが必要

重要なブランチを保護する利点の1つは、本番環境にマージする前に、コード変更に対する共同作業者のレビューを受けることができることです。変更をマージする権限を持つ人は、誰でもプルリクエストに対してレビューを提出できます(デフォルトでは、リポジトリの所有者とエディター)。

以下のレビューポリシーを適用することができます。

  • マージ前に拒否がないことが必要 - これにより、レビュワーのうち少なくとも1人がコード変更を拒否した場合、プルリクエストのマージがブロックされます。
  • マージ前に少なくとも1つの承認が必要 - これにより、コードがレビューされ、承認されることが確認されます。

特定のレビュワーが必要

特定のユーザーまたはグループからの承認が必要であるように設定し、プルリクエストがマージされる前に要求できます。グループ要件を満たすためには、グループのメンバーのうち少なくとも1人がプルリクエストを承認する必要があります。このポリシーは、承認が得られた限り、拒否を許可します。たとえば、グループのメンバーが1人が変更を拒否し、もう1人が承認した場合、拒否がないことが必要なポリシーが適用されない限り、承認が拒否を上書きします。

警告

ユーザー/グループの承認を必要とすることは、彼らにプルリクエストをレビューする権限を与えません。必要なレビュワーがコードリポジトリにアクセスできることを常に確認してください。

高度な承認ポリシーの設定

高度なプルリクエスト承認ポリシーは、プルリクエストで変更されたファイルに基づいて、レビューが必要なユーザーやグループを決定します。保護されたブランチのブランチ設定で、編集、次いで 高度な承認ポリシー を選択して、ポリシーの設定を開始します。

高度な承認ポリシーエディタ。

Edit policy タブはフォームベースのエディタを提供します。高度な承認ポリシーは、ALLANY などのルールの論理演算子をグループ化します。ルールを選択して、ルールの名前や説明などのメタデータを提供します。Rule applies conditionally をオンにすると、プルリクエストで変更されたファイルが一定の正規表現に一致する場合にのみ、このルールが適用されます。

View YAML タブでは、ポリシーの YAML 表現を直接変更、コピー、貼り付けできます。これは、ポリシーに対して一括編集を行う場合に便利です。たとえば、検索語を見つけて置き換えることができます。

セキュリティ承認が必要

ブランチで セキュリティマーキング を伝播させるのを止めるには、ブランチを保護する必要があります。リポジトリでセキュリティ変更が有効になると、プルリクエストをマージする前にセキュリティチェックと承認(必要な場合)が自動的かつ不変的に必要になります。継承されたマーキングの削除について詳しく読んでください。

フォールバックブランチ

Code Repositories では、任意のブランチでデータセットをビルドし、データに対する変換の影響を確認できます。現在のブランチで入力データセットがビルドされていない場合、フォールバックブランチ のリストから代わりにビルドされたバージョンを見つける試みが行われます。デフォルトブランチは、別の設定がない限り、フォールバックブランチとして自動的に設定されます。必要に応じて、各ブランチに異なるフォールバックブランチを設定し、複数のフォールバックを持つことができます。

この設定は、設定された Code Repository でのビルドとアクションにのみ適用されます。リポジトリ外でトリガーされるビルドや、Foundry の他のアプリケーションには影響しません(例えば、スケジュールされたビルドを使用しています)。