注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ブランチ設定
このページでは、Code Repositories のさまざまなブランチ設定について説明します。
デフォルトブランチ
複数のブランチがある Code Repositories では、デフォルトブランチをベースブランチとして設定できます。デフォルトでは、別のブランチを選択しない限り、すべてのプルリクエストとコミットはそのブランチに対して行われます。通常、デフォルトブランチは master ブランチです。
コードリポジトリのメインブランチは、Settings > Branches > Default branch に移動して選択できます。
マージモード
プルリクエストで提案されたコードの変更をマージする方法はいくつかあります。設定タブでは、プルリクエストページでコード作成者が利用可能なマージモードを1つ以上選択できます。
- コミットをまとめてマージ - コミットをまとめてマージするモードでは、プルリクエストに含まれるすべての変更を組み込んだ単一のコミットが対象ブランチに作成されます。これにより、デフォルトブランチのコミット履歴がより簡潔になります。
- マージ - プルリクエストでマージを使用すると、ブランチで作成されたすべての個別のコミットが、マージコミットとともに対象ブランチに追加されます。対象ブランチのコミット履歴では、すべての個別のコミットが元のタイムスタンプ付きで表示され、開発ブランチで作成された時刻を示します。
- ファストフォワードでマージ - 対象ブランチからこのブランチへの直接の経路がある場合（対象ブランチに追加の変更がない場合）、ファストフォワードでマージすると、対象ブランチが開発ブランチの先端まで進められ、両者のコミット履歴が統合されます。
選択したすべてのマージモードは、プルリクエストページに選択肢として表示されます。「コミットをまとめてマージ」モードを選択した場合は、それがメインの選択肢として表示され、ほかの選択したモードはメニューから利用可能になります。
保護されたブランチ
同じコードリポジトリで複数の作成者が作業している場合や、リポジトリが重要なデータ資産の元になっている場合は、このブランチを保護することで、ガバナンスを強化し、意図しない変更を防止できます。保護されたブランチはプルリクエストを通じてのみ変更でき、事前に定義された要件を満たす必要があります。
デフォルトでは、コードリポジトリの所有者のみがブランチ保護設定を変更できます。一方、所有者と編集者はどちらも保護されたブランチにプルリクエストをマージできます。権限にかかわらず、コードの作成者はすべて、保護されたブランチのポリシーに従う必要があります。
ブランチ設定パネルでは、次の要件を設定できます。
- ci/foundry-publish の正常な実行を必須にする
- コードレビューを必須にする
- 特定のレビュー担当者を必須にする
- セキュリティ承認を必須にする
- 安定バージョンのタグを制限する（Functions リポジトリのみ）
ci/foundry-publish の正常な実行を必須にする
データへの変更を公開するには、継続的インテグレーションのプロセス ci/foundry-publish が実行され、正常に完了する必要があります。正常に完了する前に変更をマージした場合、変更が反映される保証はありません。そのため、保護されたブランチでは、これを要件にすることを強く推奨します。
コードレビューを必須にする
重要なブランチを保護する利点の1つは、コードの変更を本番環境にマージする前に、共同作業者のレビューを受けられることです。変更をマージする権限を持つユーザーは誰でも、プルリクエストのレビューを送信できます（デフォルトでは、リポジトリの所有者と編集者）。
次のレビューポリシーを適用できます。
- マージ前に却下がないことを必須とします - レビュー担当者の1人以上がコードの変更を拒否した場合、プルリクエストのマージをブロックします。
- マージ前に1名以上の承認を必須とします - 変更をマージする前に、コードがレビューされ、承認されることを保証します。
特定のレビュー担当者を必須にする
プルリクエストをマージする前に、特定のユーザーまたはグループによる承認を必須にできます。グループの要件を満たすには、そのグループのメンバー1人以上がプルリクエストを承認する必要があります。このポリシーを単独で適用した場合、承認が得られていれば、拒否があってもマージできます。たとえば、グループのあるメンバーが変更を拒否し、別のメンバーが承認した場合、「拒否がないことを必須にする」ポリシーが適用されていない限り、承認が拒否に優先します。
ユーザーやグループの承認を必須にしても、プルリクエストをレビューする権限が付与されるわけではありません。必須のレビュー担当者にもコードリポジトリへのアクセス権があることを必ず確認してください。
詳細承認ポリシーを設定する
詳細なプルリクエスト承認ポリシーでは、プルリクエストで変更されたファイルに基づいて、レビューが必要なユーザーとグループを決定します。ポリシーの設定を開始するには、保護されたブランチのブランチ設定で編集を選択し、次に詳細承認ポリシーを選択します。
ポリシー編集タブには、フォームベースのエディターがあります。詳細承認ポリシーは、ALL や ANY などのルールの論理演算子をグループ化します。ルールを選択すると、ルールの名前や説明などのメタデータを入力できます。ルールは条件付きで適用されますをオンにすると、プルリクエストで変更されたファイルが正規表現に一致する場合にのみ、このルールが適用されます。たとえば、Python トランスフォームの一般的なフォルダー構造では、["transforms-python/src/myproject/datasets/.*\\.py"] は datasets フォルダー内のすべての Python ファイルに一致します。
YAML を表示タブでは、ポリシーの YAML 表現を直接変更、コピー、貼り付けできます。これは、検索語の検索と置換など、ポリシーを一括編集する際に便利です。
セキュリティ承認を必須にする
ブランチでセキュリティマーキングの伝播を停止するには、そのブランチが保護されている必要があります。リポジトリでセキュリティ変更を有効にすると、プルリクエストをマージする前のセキュリティチェックと承認（必要な場合）が自動的に必須となり、この要件は変更できません。継承されたマーキングの削除について詳しくは、こちらを参照してください。
安定バージョンのタグを制限する
Functions リポジトリでは、Functions の安定バージョンのリリースに制限を適用できます。リポジトリに保護されたブランチを1つ以上設定すると、安定版は保護されたブランチからのみタグ付け可能にするという追加のトグルが利用可能になります。
安定版は保護されたブランチからのみタグ付け可能にするを有効にすると、リポジトリのフィーチャーブランチ（保護されていないブランチ）からタグ付けする際に、安定したセマンティックバージョンの文字列を送信できなくなります。たとえば、1.2.3 は安定したセマンティックバージョンですが、1.2.3-rc1 はプレリリースバージョンを表し、フィーチャーブランチからのタグ付けが許可されます。
Functions を呼び出すアプリケーションは、バージョン範囲を参照するように設定されている場合があります。たとえば、Workshop モジュールがバージョン >=1.2.3 <2.0.0 の Function foo を呼び出す場合、バージョン 1.3.0 をリリースすると、Workshop モジュールはこのバージョン（1.3.0）を呼び出すようになります。
新しいバージョンによる予期しない動作を防ぐため、新しい安定バージョンとしてリリースする前に、コードの変更をレビューし、テストすることを推奨します。保護されたブランチにマージするには、変更がコードレビューを経る必要があるため、安定版は保護されたブランチからのみタグ付け可能にするトグルにより、すべての変更が安定バージョンとしてリリースされる前にレビューされることが保証されます。
バージョン範囲ではプレリリースバージョンが無視されるため、1.3.0-test のようなプレリリースバージョンを公開すれば、下流のアプリケーションが新しいリリースを呼び出すのを防げます。安定版は保護されたブランチからのみタグ付け可能にするトグルを有効にしても、フィーチャーブランチからプレリリースバージョンをリリースできます。そのため、本番環境で問題を引き起こすことなく、下流のアプリケーションでバージョンをテストできます。
ブランチの保護を解除する
所有者はコードリポジトリの設定からブランチの保護を解除できます。ただし、マーキングの伝播停止など、アクティブなセキュリティ変更があるブランチは、そのセキュリティ変更がなくなるまで保護を解除できません。アクティブなセキュリティ変更があるブランチの保護を解除するには、プルリクエストを通じて変更を取り除く必要があります。その後、コードリポジトリの設定からブランチの保護を解除できます。
フォールバックブランチ
Code Repositories では、任意のブランチでデータセットをビルドし、トランスフォームがデータに与える効果を表示できます。トランスフォームの入力データセットが現在のブランチでビルドされていない場合は、代わりにフォールバックブランチのリストからビルド済みのバージョンを探します。別途設定しない限り、デフォルトブランチが自動的にフォールバックブランチとして設定されます。ブランチごとに異なるフォールバックブランチを設定でき、必要に応じて複数のフォールバックブランチを設定することもできます。
この設定は、設定先のコードリポジトリ内で実行されるビルドと操作にのみ適用されます。他の Foundry アプリケーションや、リポジトリ外でトリガーされるビルド（たとえば、スケジュールされたビルドを使用する場合）には影響しません。
また、Code Repositories のブランチと同じ名前の Pipeline Builder ブランチを設定することで、Pipeline Builder のトランスフォームが、その一致するブランチから入力データセットを読み込むようにできます。Pipeline Builder もフォールバックブランチの設定をサポートしているため、入力データセットが現在のブランチでビルドされていない場合に、どのブランチを使用するかを制御できます。