11. まとめ

振り返り

このハンズオンでは、次の流れを体験しました。

1. ローカルリポジトリを準備
2. GitHub でリモートリポジトリを作成
3. GitHub でイシューを作成
4. develop と feature ブランチ で変更を分離
5. イシューを起点にしたコード変更
6. Pull Request の CI とレビューを確認
7. develop から main へリリース
8. GitHub Pages の CD と公開結果を確認

成果物を確認する

• Issue に背景と完了条件がある
• feature Pull Request と release Pull Request がある
• CI が成功している
• Pages Workflow が成功している
• 公開サイトで変更を確認できる

このハンズオンで身につけたこと

このハンズオンでは、コードの変更だけでなく、要望を受け取ってから利用者へ届けるまでの開発フローを一通り体験しました。ここで身につけた考え方は、ほかの言語やアプリケーションを扱う場合にも応用できます。

要望を検証可能な要件へ変換する

Issue に背景と完了条件を記載し、実装担当者とレビュー担当者が同じ基準で判断できる状態を作りました。境界値や期待結果を具体的にすると、実装後に完了を客観的に確認できます。

変更を安全に分離して統合する

feature ブランチで作業を分離し、Pull Request を通じて develop、main の順に統合しました。ブランチごとの役割を決めることで、未完成の変更を公開対象から分離し、変更の履歴を追跡できます。

テストと CI で品質を確認する

期待する振る舞いをテストで表現し、ローカルと CI の両方で実行しました。ローカルでは問題を素早く発見し、CI では開発環境や実行者に左右されない共通の品質基準を適用できます。

レビューを品質向上と知識共有に活用する

Issue、差分、テスト、CI を根拠に Pull Request をレビューしました。行単位のコメントやレビュー結果を履歴として残すことで、変更の意図を共有し、チームのレビュー観点を次の開発へ引き継げます。

リリースとデプロイを追跡する

develop から main への変更をリリース単位で確認し、GitHub Pages の Workflow と公開結果まで追跡しました。Issue、コミット、Pull Request、Workflow、公開サイトを関連付けることで、変更がどこまで進んでいるかを確認できます。

GitHub Copilot を作業方法の1つとして使う

GitHub Copilot、PowerShell、Bash、GitHub.com (Web) から、状況に合う方法を選びました。GitHub Copilot を利用する場合も、提案をそのまま採用せず、Issue、差分、テスト、CI の結果を根拠に最終判断することが重要です。

クリーンアップ

リポジトリを残して Pages だけ停止する

公開停止

OWNER/REPOSITORY が演習用リポジトリであることを確認してください。公開サイトが削除されます。

Pages とデプロイ Workflow を停止し、リポジトリを残したまま公開 URL が利用できない状態にします。

Agent モードで以下の指示を与えます。

プロンプト内の OWNER/REPOSITORY を演習用リポジトリへ置き換えます。

既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
対象 OWNER/REPOSITORY が今回の演習用リポジトリであることを remote、リポジトリ情報、Pages URL から確認してください。
これから Deploy GitHub Pages Workflow を無効化し、Pages サイトを削除すること、公開 URL が利用不能になること、リポジトリ自体は残ることを、対象と現在値を含めて要約してください。
askQuestions で対象名と2つの破壊的操作への明示的な承認を得るまで実行しないでください。対象不明、値不一致、権限不明なら何も変更せず質問してください。
承認後だけ実行し、Workflow の無効化と Pages サイト削除を読み取り確認して報告してください。

次を確認します。

• 対象が今回の演習用リポジトリである
• Workflow の無効化、Pages サイト削除、公開 URL への影響を個別に確認して明示的に承認するまで実行されていない
• リポジトリ自体は残っている
• Workflow が無効で、Pages サイトが削除されたことが報告されている

公開 URL へアクセスし、サイトが利用できないことを確認します。

リポジトリごと削除する

リポジトリを削除すると、GitHub Pages の公開サイトも削除されます。

削除操作

次の操作はリポジトリを削除し、元に戻せません。OWNER/REPOSITORY が演習用であることを確認してから実行してください。

演習用リポジトリを完全に削除し、コード、履歴、Issue、Pull Request、Pages が残っていないことを確認します。

Agent モードで以下の指示を与えます。

プロンプト内の OWNER/REPOSITORY を演習用リポジトリへ置き換えます。

既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
対象 OWNER/REPOSITORY が今回の演習用リポジトリであることを remote と GitHub のリポジトリ情報から確認し、Owner、名前、visibility、URL、Pages 公開の有無を示してください。
リポジトリ削除によりコード、Issue、Pull Request、Actions 履歴、Pages サイトが削除され元に戻せないことと、delete_repo scope が必要な場合の権限影響を要約してください。
askQuestions で完全なリポジトリ名を再入力させ、権限追加と永久削除を個別に明示承認されるまで、認証変更も削除も実行しないでください。対象不明や不一致なら何も変更せず質問してください。
承認後だけ必要な認証と削除を行い、対象が存在しなくなったことを確認して報告してください。

次を確認します。

• Owner、リポジトリ名、visibility、URL、Pages 公開の有無が意図した対象と一致している
• 削除されるコード、Issue、Pull Request、Actions 履歴、Pages サイトと、操作を元に戻せないことが示されている
• 完全なリポジトリ名の再入力と、権限追加、永久削除の明示的な承認が個別に得られるまで実行されていない
• 承認後、対象リポジトリが存在しないことが報告されている

ローカルの演習フォルダーも、不要になった時点で削除します。

次のステップ

ここまでの内容を土台に、関心のある分野を選んで学習を続けます。

GitHub の基本操作を定着させる

GitHub Learn では、リポジトリ、Issue、Pull Request、レビューなどを実際に操作しながら学べます。まずは本ハンズオンで不慣れだった操作に近いコースを選び、別のリポジトリでも同じ開発フローを再現してみてください。

GitHub Actions を深く学ぶ

Microsoft Learn の GitHub Actions を使用してワークフローを自動化するでは、Workflow の構成、CI、デプロイ、GitHub API を使った自動化を体系的に学べます。次は、Linter、静的解析、テスト、ビルドを組み合わせた品質ゲートの設計へ進むとよいでしょう。

GitHub Copilot の活用範囲を広げる

Microsoft Learn の GitHub Copilot の概要では、GitHub Copilot の基本機能、設定、利用方法を確認できます。本ハンズオンで使用した Agent Skill やレビュー観点を、自分のプロジェクト向けに調整することも次の実践課題になります。

認定資格で知識を体系化する

GitHub の機能を広く学ぶ場合は GitHub Foundations から始めます。その後、目標に応じて GitHub Actions または GitHub Copilot の認定資格へ進むと、本ハンズオンで体験した内容をより体系的に整理できます。