GitHubは、コードの管理から共同開発、自動化、公開まで幅広く支えるプラットフォームとして、多くの開発現場で欠かせない存在です。一方で、Gitの基本操作やプルリクエスト、Actionsなどの機能は、使い慣れていても意外と曖昧なままの部分があるものです。この記事では、GitHubにまつわる知識を10問のクイズで手軽に確認できます。初心者の方は基礎固めに、経験者の方は知識の再点検にどうぞ。全問正解を目指して、気軽に挑戦してみてください。
Q1 : GitHub Pagesの説明として正しいものはどれ? PHPなどのサーバーサイドプログラムを実行できる データベースを標準で提供し、動的なサイトを構築できる HTML、CSS、JavaScriptなどの静的ファイルをホスティングできる Dockerコンテナを常時起動して外部に公開できる
GitHub Pagesは、リポジトリ内のHTML、CSS、JavaScriptなどの静的ファイルを、そのままWebサイトとして公開できるホスティングサービスです。個人のポートフォリオ、ドキュメント、ブログなどによく使われます。また、Jekyllによる静的サイト生成にも対応しています。サーバーサイドのコード(PHPなど)の実行、データベースの提供、コンテナの常時稼働といった動的な処理はできないため、そのような用途には別のホスティングサービスが必要です。
Q2 : 2021年8月13日以降、GitHubへのGit操作(HTTPS経由)でアカウントのパスワード認証が廃止された。代わりに使用する認証方法はどれ? SMSで届く確認コード Personal access tokenまたはSSHキー 登録メールアドレスのみ CAPTCHA認証
GitHubは2021年8月13日から、Git操作におけるパスワード認証を廃止しました。現在は、HTTPSではPersonal access token(PAT)をパスワードの代わりに使い、SSHではSSHキーを登録して認証を行います。これは、パスワードの漏えい時のリスクを減らし、権限範囲や有効期限を細かく管理できるようにするための変更です。SMSコードは二要素認証で使われ、メールアドレスのみやCAPTCHAはGit操作の認証方法ではありません。
Q3 : GitHub Codespacesとは何か? プルリクエストのコードレビューを自動化するツール パッケージを公開・配布するためのレジストリ 静的サイトを公開するホスティングサービス クラウド上に構築され、ブラウザやエディタから利用できる開発環境
GitHub Codespacesは、クラウド上に用意される開発環境を提供するサービスです。リポジトリから直接起動でき、ブラウザ上のVisual Studio Codeや、ローカルのVS Codeから接続して開発できます。devcontainer.jsonで環境を定義しておけば、チーム全員が同じ構成で素早く開発を始められ、ローカル環境の構築が不要になります。パッケージの配布はGitHub Packages、静的サイトの公開はGitHub Pagesという別の機能が担当します。
Q4 : GitHub Actionsのワークフローを定義するYAMLファイルは、リポジトリのどのディレクトリに配置する? `.actions/` `.github/actions/` `.github/workflows/` `workflows/`
GitHub Actionsのワークフローファイルは、リポジトリ直下の.github/workflowsディレクトリにYAML形式(.ymlまたは.yaml)で配置します。このディレクトリに置かれたファイルが自動的にワークフローとして認識され、push、pull_request、scheduleなどのイベントをトリガーに実行されます。.github/actionsは、リポジトリ内に独自のカスタムアクションを置く際に慣例的に使われる場所で、ワークフロー定義そのものの置き場所ではありません。
Q5 : プルリクエストの説明文に「Closes #123」と書いてデフォルトブランチにマージすると、何が起こる? Issue #123が自動的にクローズされる Pull Request #123が自動的に削除される Issue #123にラベルが自動で付与される ブランチ #123 が新しく作成される
GitHubには、プルリクエストとIssueを関連付けるキーワード機能があります。closes、fixes、resolvesなどのキーワードの後にIssue番号を書き、そのプルリクエストがデフォルトブランチにマージされると、該当Issueが自動的にクローズされます。手作業でのクローズ忘れを防げるため、多くの開発現場で使われています。なお、この自動クローズはデフォルトブランチへのマージ時に働く点に注意が必要で、他のブランチへのマージでは作動しません。
Q6 : GitHubのCODEOWNERSファイルの主な役割はどれ? リポジトリのライセンス条項を定義する 特定のファイルやディレクトリに対するレビュー担当者を自動で指定する リポジトリの管理者権限を持つユーザーを決定する コミットに署名できるユーザーを制限する
CODEOWNERSファイルには、ファイルパスのパターンと、それを担当するユーザーまたはチームを記述します。該当ファイルを変更するプルリクエストが作られると、担当者が自動的にレビュー依頼の対象になります。ブランチ保護ルールで「コードオーナーのレビューを必須にする」を有効にすると、承認なしにはマージできなくなります。配置場所はリポジトリのルート、docsディレクトリ、または.githubディレクトリのいずれかです。ライセンスの定義や管理者権限の決定とは関係ありません。
Q7 : プルリクエストのマージ方法のうち、PR内の複数のコミットを1つのコミットにまとめてベースブランチに追加するものはどれ? Create a merge commit Rebase and merge Close pull request Squash and merge
Squash and mergeは、プルリクエストに含まれるすべてのコミットを1つにまとめて、ベースブランチへ追加するマージ方法です。作業中の細かいコミットやFix typoのようなコミットを整理でき、メインブランチの履歴をすっきり保てます。Create a merge commitは全コミットを保持したままマージコミットを作成し、Rebase and mergeは各コミットをベースブランチの先頭に付け替えて追加します。Close pull requestはマージせずにPRを閉じるだけです。
Q8 : GitHubのDependabotの機能として正しいものはどれ? 依存関係の脆弱性を検知して警告し、更新用のプルリクエストを自動で作成できる ソースコードを自動でコンパイルして実行ファイルを生成する プルリクエストのコードレビューを人間に代わって承認する リポジトリのアクセス権限を自動的に付与する
Dependabotは、GitHubが提供する依存関係管理の機能です。プロジェクトが利用するライブラリに既知の脆弱性があるとアラートを出し、Dependabot security updatesを有効にすると修正版へ更新するプルリクエストを自動作成します。また、dependabot.ymlの設定により、脆弱性の有無に関わらず定期的にバージョン更新のプルリクエストを作らせることも可能です。コンパイル、レビュー承認、権限付与といった機能は持っていません。
Q9 : Gitでリモートリポジトリの最新情報をローカルに取得するが、作業中のブランチには自動でマージしないコマンドはどれ? git pull git fetch git merge git clone
git fetchは、リモートリポジトリの最新のコミットやブランチ情報をローカルに取得しますが、現在作業中のブランチにはマージしません。そのため、変更内容を確認してから取り込むか判断できます。一方のgit pullは、git fetchに続けてgit mergeまたはgit rebaseを実行するのと同等の操作で、取得と同時に統合まで行います。git cloneはリポジトリ全体を新規に複製するコマンド、git mergeはブランチ同士を統合するコマンドです。
Q10 : 他人が公開しているリポジトリに修正を提案したいとき、まず自分のアカウント配下にリポジトリのコピーを作成するGitHubの操作はどれ? Star Watch Clone Fork
Forkは、他のユーザーのリポジトリを自分のアカウント配下に複製するGitHubの機能です。書き込み権限のないリポジトリでも、Forkした自分のコピーで自由に変更でき、その後プルリクエストで元のリポジトリに変更を提案できます。Starはお気に入り登録、Watchは通知の購読設定です。Cloneは、リポジトリをローカルPCへ複製するGitの操作であり、GitHub上にコピーを作るものではありません。
