ブランチマージ制限を実装する
Azure DevOps と GitHub によってホストされるバージョン管理システムでのブランチのマージ制限は、コード品質の制御、コラボレーションの促進、ソフトウェア開発プロジェクトの安定性の向上に不可欠です。 これらは、組織がコード レビューを強制し、自動テストが正常に完了したことを検証し、指定されたブランチへのフォース プッシュを防止するのに役立ちます。 これらの制約は、コードベースの整合性を維持し、偶発的な変更を防ぎ、検証および承認された変更のみが本番ブランチにマージされるようにするのに役立ちます。
ブランチのマージ制限の一般的な概念は、プラットフォームに依存しません。 Azure DevOps と GitHub の実装は多少異なりますが、類似点も多く、ほとんどの部分で両者の機能は同等です。
Azure DevOps
Azure DevOps では、ブランチ保護ベースのポリシーを使用して、ブランチのマージ制限を実装できます。
ブランチ保護を実装するには、Azure DevOps ポータルでリポジトリに移動し、マージ制限を適用するブランチを選択します。 あるいは、指定したパターンに一致する現在および将来のブランチに保護のスコープを設定することもできます。 保護構成の一部として、次のブランチ ポリシーを適用できます。
- レビュー担当者の最少数が必要です: 必要な数の承認がなければ変更をマージできないようにします。
- リンクされた作業項目を確認します: pull requests 時に、リンクされた項目を確認して、追跡可能性を強化します
- コメント解決の有無を確認する: pull request 時に、すべてのコメントが解決されたことを確認します
- マージの種類を制限する: pull request が完了した際に使用できるマージの種類を制限することでブランチ履歴を制御します。 これには、次のマージの種類を選択的に有効または無効にするオプションが含まれます。
- 基本マージ (早送りなし): 開発中に生じたとおりに、履歴をそのまま保持します。
- リベースと早送り: マージ コミットせずに、ソース ブランチのコミットをターゲットに対して再生することにより線形履歴を作成します。
- スカッシュ マージ:ソース ブランチのコミットを、ターゲット ブランチで 1 つの新しいコミットにまとめることにより、線形履歴を作成します。
- マージ コミットによるリベース:ターゲットに対してソース ブランチのコミットを再生し、その後マージ コミットを作成することで、半線形履歴を作成します。
オプションで、次の設定を構成できます。
- ビルドの検証: pull request の変更を事前にマージし、ビルドすることによって、コードを検証します。
- 状態の確認: 正常な状態を投稿して pull request を完了するには他のサービスが必要です。 状態の確認は、pull request プロセス中にトリガーされる自動化されたタスクであり、pull request をターゲット ブランチにマージする前に特定の条件を検証します。 Azure DevOps では、状態の確認はビルド パイプラインとリリース パイプラインに関連付けられます。
- レビュー担当者を自動的に含める: pull request がコードの特定の領域を変更するときに、コード レビューアーが自動的に追加されるように指定します。
ブランチをロックして、実質的に読み取り専用にするオプションもあります。
Azure DevOps には、リポジトリのポリシー要件をバイパスするための 2 つのオプションが用意されていることに注意してください。 それらを実装するには、次のアクションを実行するアクセス許可を [許可] に設定して、リポジトリの既定のセキュリティ構成を変更する必要があります。
- [Bypass policies when completing pull requests](pull request 完了時にポリシーをバイパス)。
- [Bypass policies when pushing](プッシュ時にポリシーをバイパス)。
これらのアクセス許可は、組織標準への準拠に対するこれらのアクションの影響を理解し、その使用に関して適切な判断を行うことができる指定された個人にのみ付与されるようにすることが重要です。
GitHub
GitHub では、ブランチ保護ルールを使用してブランチのマージ制限を実装できます。 ブランチ保護ルールでは、コラボレーターがブランチを削除または強制的にプッシュできるかどうかを定義し、ステータス チェックや線形コミット履歴の受け渡しなど、ブランチへのプッシュの要件を設定できます。 Azure DevOps と同様に、名前パターンの一致に基づいて特定のブランチに適用できます。
ブランチ保護ルールを実装するには、GitHub Web インターフェースでリポジトリに移動し、ナビゲーション メニューの [Settings] タブで [Branches] メニュー項目を選択します。 これにより、ブランチ保護ルールの構成にアクセスできるようになります。 保護構成の一部として、次のルールを適用できます。
- Require a pull request before merging: 共同作成者は変更をマージする前に、レビューと承認のために pull request を送信する必要があります。
- Require status checks to pass before merging: は、マージを許可する前に合格する必要があるステータス チェックを指定します。 有効にすると、状態チェックに合格した後に、コミットはまず別のブランチにプッシュされ、マージされるか、この規則に一致するブランチに直接プッシュされる必要があります。
- Require conversation resolution before merging: pull request をマージする前に、コード変更に関連するすべてのディスカッションとコメントが解決されていることを確認します。
- Require signed commits: 保護されたブランチにプッシュされたコミットは検証済みの署名で署名されます。これにより、セキュリティが強化され、コードのコントリビューションの信頼性が確保されます。
- Require linear history: 保護されたブランチでのマージ コミットを防止し、線形履歴を強制します。これにより、変更の追跡や、必要に応じて変更を元に戻すことが容易になります。 これは、実質的に、すべての pull request でスカッシュ マージまたはリベース マージを使用する必要があることを意味します。
- Require deployments to succeed before merging: コードベースに統合する前に、pull request で提案された変更を徹底的にテストして検証することを指示します。
- Lock branch: Azure Devops と同等の機能として、ブランチへの書き込みアクセス権限を制限し、読み取り専用にします。
- Do not allow bypassing the above settings: ブランチ保護のバイパス権限を付与された管理者およびユーザーによって他のルールがバイパスされる可能性を排除します。
- Allow force pushes: プッシュ特権を持つユーザーによる変更の強制プッシュを許可します。 Azure DevOps と同様に、これは緊急時の対策としてのみ使用されます。
- Allow deletions: プッシュ特権を持つユーザーによる保護されたブランチの削除を許可します。 この柔軟性によりブランチ管理が効率化される一方で、誤って、または悪意をもってブランチが削除されるリスクも生じるため、データの損失を防ぎ、リポジトリの整合性を維持するために慎重に制御する必要があります。