はじめに
ルールセットを作成して、ユーザーがリポジトリ内で選んだブランチとタグを操作する方法を制御できます。 どのユーザーが特定のブランチにコミットをプッシュできるか、コミットをどのようにフォーマットする必要があるか、どのユーザーがタグを削除または名前変更できるかといったことを制御できます。 また、ユーザーがリポジトリの名前を変更できないようにすることもできます。
ルールセットを作成するときに、特定のユーザーがルールセットの中のルールをバイパスすることを許可できます。
このルールセットについて詳しくは、「ルールセットについて」をご覧ください。
組織内のすべてのリポジトリのルールセットを作成することもできます。 詳しくは、「組織内のリポジトリのルールセットを作成する」をご覧ください。
fnmatch
構文の使用
fnmatch
構文を使用 して、ルールセットの作成時にターゲットとするパターンを定義できます。
*
ワイルドカードを使って、任意の文字列に一致させることができます。 GitHub では File::FNM_PATHNAME
フラグを File.fnmatch
構文で使うため、*
のワイルドカードがディレクトリの区切り記号 (/
) と照合されません。 たとえば、qa/*
は、qa/
で始まり、1 つのスラッシュを含むすべてのブランチと照合されますが、qa/foo/bar
とは照合されません。 qa
の後には、qa/**/*
を使用して任意の数のスラッシュを含めることができます。これは、たとえば qa/foo/bar/foobar/hello-world
と一致します。 qa**/**/*
を使い qa
の文字列を拡張して、より包括的にすることもできます。
構文のオプションについて詳しくは、fnmatch のドキュメントを参照してください。
コミット メタデータに正規表現を使用する
ブランチまたはタグをターゲットとするルールセットにメタデータ制限を追加するときは、正規表現構文を使って、コミット メッセージ、ブランチ名またはタグ名などの関連するメタデータが一致する必要がある、または一致してはならないパターンを定義できます。
既定では、メタデータの制限は正規表現パターンを受け入れません。 これを有効にするには、ルールセットのメタデータ制限を作成するときに、[特定の正規表現パターンに一致する必要がある] を選択します。
ルールセットでは、RE2 構文がサポートされています。 詳しくは、Google の構文ガイドに関するページをご覧ください。 式を検証するには、regex101.com の検証コントロールを使い、左側のサイドバーで "Golang" フレーバーを選択できます。
既定では、メタデータ制限の正規表現では、複数行のテキストは考慮されません。 たとえば、複数行のコミット メッセージがある場合、パターン ^ABC
は、メッセージの最初の行が ABC
で始まっていれば一致します。 複数行のメッセージと一致させるには、表現を (?m)
で開始します。
?!
で示される負の先読みアサーションはサポートされていません。 ただし、特定の文字列の後に別の特定の文字列が続いていないケースを検索する必要がある場合は、?
で示される正の先読みアサーションを、"特定の正規表現パターンと一致してはならない" という要件と組み合わせて使用できます。
注: 共同作成者にコミットのサインオフを要求する場合は、それが正規表現のパターンを妨げる可能性があります。 ユーザーがサインオフすると、GitHub によって Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL>
のような文字列がコミット メッセージに追加されます。 詳しくは、「Organization のコミット サインオフ ポリシーの管理」を参照してください。
便利な正規表現パターン
次の例では、コミット メタデータに役立つパターンを示します。 これらのパターンを使用するには、 [要件] を [特定の正規表現パターンに一致する必要がある] に設定します。
ブランチ名が Windows と互換性があることを確認する
次のパターンを使って、ブランチ名に数字、小文字、文字 -
と _
のみが含まれることを確認できます。 これにより、ブランチ名が、既定で大文字と小文字を区別するファイル システムを使用しないオペレーティング システムと互換性があることが確認されます。
\A[0-9a-z-_]$
\A[0-9a-z-_]$
一致する: my-branch
一致しない: myBranch
タグ名でセマンティック バージョン管理が使用されていることを確認する
次のパターンを使って、タグ名がセマンティック バージョン管理に準拠していることを確認できます。 詳しくは、semver.org のドキュメントをご覧ください。
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
一致する: 1.2.3
、10.20.30
、1.1.2-prerelease+meta
一致しない: 1.2
、1.2-SNAPSHOT
コミット メッセージの行の長さを制限する
Pro Git の書籍では、コミット メッセージの最初の行を約 50 文字に制限することが推奨されています。
次のパターンを使って、コミット メッセージの最初の行が 50 文字以下であることを確認できます。
\A.{1,50}$
\A.{1,50}$
コミット メッセージが解決と issue 番号で始まっていることを確認する
次のパターンを使って、コミット メッセージに Resolves:
または Fixes:
という単語と、それに続く #1234
のような文字列が含まれていることを確認できます。
^(Resolves|Fixes): \#[0-9]+$
^(Resolves|Fixes): \#[0-9]+$
一致する: Fixes: #1234
一致しない: Add conditional logic to foo.bar
従来のコミットを適用する
次のパターンを使って、コミット メッセージが従来のコミット仕様に準拠していることを確認できます。 詳しくは、conventionalcommits.org をご覧ください。
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)
一致する: feat: allow provided config object to extend other configs
一致しない: Add conditional logic to foo.bar
ルールセットの適用ステータスの使用
ルールセットの作成または編集中に、適用ステータスを使用してルールセットの適用方法を構成できます。
ルールセットには、次の適用ステータスのいずれかを選択できます。
- アクティブ: ルールセットは作成時に適用されます。
- 評価: ルールセットは適用されませんが、「ルールの分析情報」ページでルールに違反するアクションと違反しないアクションを監視できます。
- 無効: ルール セットは、 または評価 に適用されません。
「評価」モードを使用することは、ルールセットを適用せずにテストするための優れたオプションです。 「ルールの分析情報」ページを使用して、そのコントリビューションがルールに違反したかどうかを確認できます。 詳しくは、「リポジトリのルールセットの管理」を参照してください。
分岐またはタグルールセットの作成
-
GitHub で、リポジトリのメイン ページに移動します。
-
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
左側のサイド バーの [コードと自動化] の下で、 [ルール] をクリックし、 [ルールセット] をクリックします。
-
ブランチを対象とするルールセット、またはタグを対象とするルールセットを作成できます。
-
ブランチを対象とするルールセットを作成するには、 [新しいブランチ ルールセット] をクリックします。
-
タグを対象とするルールセットを作成するには、[] を選び、 [新しいタグ ルールセット] をクリックします。
-
-
[ルールセット名] に、ルールセットの名前を入力します。
-
必要に応じて、既定の適用ステータスを変更するには、 [無効] をクリックし、新しい適用ステータスを選択します。 適用ステータスの詳しい情報については、「ルールセットについて」を参照してください。
ブランチまたはタグのルールセットに対するバイパス アクセス許可の付与
ルールセットに対し、特定のロール、チーム、またはアプリのバイパス アクセス許可を付与できます。 バイパス アクセスの対象になるものを次に示します。
- リポジトリ管理者、organization 所有者、Enterprise 所有者。
- 保守ロール、書き込みロール、または書き込みロールに基づくカスタム リポジトリ ロール
- Teams
- デプロイ キー
- GitHub Apps
-
ルールセットのバイパスのアクセス許可を付与するには、[バイパス リスト] セクションで [バイパスの追加] をクリックします。
-
表示される [バイパスの追加] モーダル ダイアログで、バイパスアクセス許可を付与するロール、チーム、またはアプリを検索し、[提案] セクションからロール、チーム、またはアプリを選択し、[選択項目の追加] をクリックします。
-
必要に応じて、リポジトリに直接プッシュすることを許可せずにアクターにバイパスを許可するには、[常に許可] の右側にある をクリックし、次に [pull request のみ] をクリックします。
選択したアクターは、リポジトリに変更を加えるために pull request を開いて、pull request と監査ログに変更の明確な証跡を作成する必要があります。 アクターは、ブランチの保護をバイパスして、その pull request をマージすることを選択できます。
ターゲットにするブランチまたはタグの選択
ブランチまたはタグをターゲットにするには、[ターゲット ブランチ] または [ターゲット タグ] セクションで、[ターゲットの追加] を選び、ブランチまたはタグを含めるまたは除外する方法を選びます。 fnmatch
構文を使って、パターンに基づいてブランチまたはタグを含めたり除外したりできます。 詳しくは、fnmatch
構文の使用に関するページを参照してください。
複数のターゲット条件を同じルールセットに追加できます。 たとえば、既定のブランチを含め、*feature*
のパターンに一致するブランチを含めてから、not-a-feature
のパターンに一致する特定のブランチを除外することができます。
ブランチまたはタグの保護の選択
[ブランチ保護] または [タグ保護] セクションで、ルールセットに含めるルールを選びます。 ルールを選ぶと、そのルールに追加設定を入力できる場合があります。 このルールについて詳しくは、「ルールセットで使用できるルール」をご覧ください。
注: [その他の設定] セクションで [マージ前に状態チェックを必須にする] をオンにする場合:
- 必須にする各状態チェックの名前を入力できます。 要件としての状態チェックの追加を完了するには、 をクリックする必要があります。
- [マージする前にブランチを最新にする必要がある] をオンにする場合は、保護を有効にするためのチェックを定義する必要があります。
メタデータの制限追加
Note
ブランチをスカッシュ マージする場合、そのブランチに対するすべてのコミットは、ベース ブランチのメタデータ要件を満たす必要があります。
-
必要に応じて、コミット メタデータまたはブランチ名を制御するルールを追加するには、[制限] セクションで [コミット メタデータの制限] または [ブランチ名の制限] をクリックします。
-
制限の設定を構成して、[追加] をクリックします。 同じルールセットに複数の制限を追加できます。
-
特定の正規表現パターンと一致させるには、[要件] ドロップダウンで [特定の正規表現パターンに一致する必要がある] を選択します。
[一致するパターンで開始する必要がある] など、ほとんどの要件では、入力したパターンはリテラルに解釈され、ワイルドカードはサポートされません。 たとえば、
*
文字が表すのは、リテラルな*
文字のみです。より複雑なパターンの場合は、[特定の正規表現パターンに一致する必要がある] または [特定の正規表現パターンに一致しない] を選び、正規表現構文を使って、一致するパターンを定義できます。 詳しくは、GitHub Enterprise Cloud ドキュメントの
リポジトリのルールセットを表示しているすべてのユーザーは、指定した説明を表示できます。
ブランチまたはタグのルール セットの最終処理と次の手順
ルールセットの作成を完了するには、[作成] をクリックします。 ルールセットの適用ステータスが "アクティブ" に設定されている場合、ルールセットはすぐに有効になります。
ルールセットの分析情報を表示して、ルールが共同作成者にどのように影響しているかを確認できます。 適用ステータスが "評価" に設定されている場合、ルール セットがアクティブであった場合に合格または失敗したアクションを確認できます。 ルールセットの分析情報の詳細については、、「リポジトリのルールセットの管理」を参照してください。