Skip to main content

コードのデプロイ

コードをデプロイするときに、デプロイ前のチェックを検証し、マージ戦略を選択し、ブランチを効果的に管理します。

プル リクエストの最後の手順は、完了した作業をデプロイ ブランチに取り込むことです。 これは通常、変更をリリースブランチまたはメインブランチにマージすることを意味します。 その前に、変更がプロジェクトの要件を満たしていることを確認する必要があります。

デプロイ前チェックの検証

マージする前に、変更がデプロイしても安全であることを確認します。 状態チェック は、コミットがリポジトリに設定されている条件 (継続的インテグレーション ビルド、テスト、コード スキャン、デプロイ チェックなど) を満たすかどうかを示します。 プルリクエストをマージする準備ができているかどうかを、あなたやレビュー担当者が理解するのに役立ちます。

リポジトリでは、多くの場合、プル要求をマージする前に、次のような特定の条件が必要になります。

  • デプロイ パイプラインによって実行されるアプリケーションの正常性チェックや準備チェックなど、合格する必要がある必須の状態チェック。
  • 必要なレビューまたはコード所有者の承認。
  • マージ競合を解決する必要があります。

保護されたブランチでは、デプロイ ブランチが安定したままになるように、これらの要件が適用されます。

すべてのチェックが同じであるわけではありません。 GitHub Actionsなどの製品によって作成された豊富なチェックでは、詳細なログと注釈を報告できますが、簡単なコミット状態は、さまざまな接続されたシステムによって投稿できます。 これらのことを理解すると、pull request が準備ができているか、準備ができていない理由を解釈するのに役立ちます。

コードをリリースブランチまたはメインブランチにマージする

要件が満たされたら、pull request をマージして、そのコミットをベース ブランチに取り込みます。 また、要件が満たされるとすぐにプル要求がマージされるようにマージを自動化することもできます。 プル要求では、リポジトリ履歴の外観に応じて異なるマージ戦略が提供されます。

  • マージ コミット では、pull request ブランチのすべてのコミットが保持され、明示的なマージ ポイントが追加されます。
  • スカッシュとマージ では、簡潔な履歴のためにすべてのコミットが 1 つのコミットに結合されます。
  • リベースとマージは、 マージ コミットなしで線形履歴のベース ブランチに各コミットを追加します。

最適な戦略は、チームが保持する詳細の量によって異なります。

大規模な要件の適用

マージが忙しくなると、チームはマージを安全かつ予測可能に保つためのコントロールを追加します。

  • ルールセットとブランチ保護 では、マージ前に、最新の状態のブランチ、署名済みのコミット、線形の履歴、または特定のステータスチェックを必須にできます。
  • マージ キューを使用すると、トラフィックの多い保護されたブランチは、中断することなく多数のプル要求を受け入れます。 各ブランチを最新バージョンのベース ブランチに対してテストし、チェックに合格すると順番にマージされます。 ブランチでマージ キューを使用する場合、使用可能なマージ オプションは標準のマージとは異なります。

メモ

pull request マージ キューは、Organization が所有するパブリック リポジトリ、または GitHub Enterprise Cloud を使っている Organization が所有するプライベート リポジトリで使うことができます。 「GitHubのプラン」を参照してください。

マージをデプロイメントに関連付ける

マージは、多くの場合、コードをリリースするきっかけになります。 GitHub Actions では、プル要求がリリースブランチまたはメイン ブランチにマージされたときに、デプロイ ワークフローを実行できます。 デプロイ環境 は、デプロイ前の安全性の別のレイヤーを追加します。展開が進む前に特定のレビュー担当者、待機タイマー、またはブランチ制限を要求することができ、これらは他のチェックと共に表示されます。

マージ後の復旧

チェック体制が整っていても、一部のマージは取り消す必要があります。 マージされたプル要求を元に戻して、変更を元に戻す新しいプル要求を作成できます。 pull request は、そのコミットが別の経路でベース ブランチに到達した場合、まれに 間接的に マージ済みとしてマークされることがあるため、ご注意ください。 これにより、その特定のプル要求の保護をバイパスできます。 「プルリクエストをリバートする」と「プルリクエストのマージ」を参照してください。

マージされない pull request を閉じる

すべてのプルリクエストをマージすべきではありません。 変更が不要になった場合、または他の作業に置き換えられる場合は、マージせずに pull request を閉じます。 終了すると、変更が進まないことを通知しながら、参照用のディスカッションと履歴が保持されます。

プル要求がマージまたは閉じられた後、そのヘッド ブランチは不要になることが多くなります。 未使用のブランチを削除すると、リポジトリの移動が容易になります。

詳細については、次を参照してください。