GitHub Foundations #4 Domain 3-1: コラボレーション — Issue・ラベル・マイルストーン・テンプレート
今回から2回にわたって、Domain 3のコラボレーション機能を扱います。コラボレーションドメインは、公式スタディガイドの基準で試験の中で最も比重が大きい領域です。GitHubをGitホスティングを超えたコラボレーションプラットフォームにした機能がすべてここに集まっており、問題数もそれだけ多く配分されます。前半である今回はIssueを中心とした作業トラッキングを、後半である次回はPull Requestを中心としたコードレビューを整理します。
Issue — 作業トラッキングの基本単位 #
Issueは、バグ報告、機能リクエスト、タスクを記録するGitHubの作業トラッキング単位です。リポジトリごとに独立したIssueリストがあり、番号はリポジトリの中で1から順に付きます。ひとつ覚えておくべき点は、IssueとPull Requestが番号体系を共有するという事実です。Issue #3の次にPRを開くと、そのPRが#4になります。
Issueには次の要素を付けられます。
- Assignees — 担当者です。1つのIssueに複数人を指定できます。
- Labels — 分類タグです。下で別に扱います。
- Milestone — Issueが属する目標のまとまりです。1つだけ指定できます。
- Projects — プロジェクトボードとの連携です。Domain 5で扱います。
メンションと参照 — @と#の区別 #
IssueとPRの本文、コメントで使う2つの記号は、試験で頻繁に区別を問われます。
- @ユーザー名 — メンションです。その人に通知を送ります。
@octocat 確認をお願いしますのように人を呼ぶ用途です。チーム単位のメンション(@org/team-name)もできます。 - #番号 — 参照です。同じリポジトリのIssueやPRへのリンクを作ります。
#12で議論した内容ですのように文書を指す用途です。
参照は方向が記録されます。Issue Aの本文で#Bを参照すると、B側のタイムラインにも「AでこのIssueが言及された」というクロスリファレンスが残ります。別リポジトリのIssueを指すときはowner/repo#番号の形式を使い、IssueのURLを本文にそのまま貼り付けてもGitHubが自動的に参照リンクへ変換してくれます。
クローズキーワード — コミットとPRでIssueを閉じる #
Issueを手で閉じる代わりに、修正がマージされたときに自動で閉じるようにできます。PR本文やコミットメッセージにクローズキーワードとIssue番号を書く方式です。
fixes #12
closes #12
resolves #123つのキーワードは効力が同じで、活用形(fixed、closed、resolvedなど)も認識されます。動作条件が試験ポイントです。デフォルトブランチ(main)にマージされる時点でIssueが閉じます。他のブランチへのマージだけでは閉じません。複数のIssueを一度に閉じるには、fixes #12, fixes #34のようにIssueごとにキーワードを繰り返す必要があります。
ラベル — 分類とフィルタリング #
ラベルは、IssueとPRを分類する色付きタグです。新しいリポジトリにはデフォルトのラベルセットが入っています。bug、documentation、duplicate、enhancement、good first issue、help wanted、invalid、question、wontfixの9種です。このうちgood first issueとhelp wantedは、オープンソースでコントリビューターを募る慣例的なラベルで、Domain 7(コミュニティ)にもつながる試験ポイントです。
ラベルはリポジトリ設定で自由に追加、編集でき、検索フィルターとして活用されます。
is:open label:bug 開いているbugラベルのIssue
is:issue assignee:@me 自分が担当者のIssue
is:open no:label ラベルのない開いたIssueマイルストーン — 目標単位のまとまり #
マイルストーンは、リリースやスプリントのように期限のある目標でIssueとPRをまとめる機能です。マイルストーンページでは、含まれるIssueのうち閉じた比率が進捗バーで表示され、期限(due date)を指定して残り時間を追跡できます。ラベルが性質による横の分類だとすれば、マイルストーンはスケジュールによる縦のまとまりです。Issue 1件にラベルは複数付けられるがマイルストーンは1つだけ、という違いも覚えておくべき点です。
Issueテンプレートとフォーム #
空のIssue様式では、報告の品質がばらつきやすくなります。リポジトリにテンプレートを置くと、Issue作成画面で様式を選んで始めるようにできます。テンプレートは.github/ISSUE_TEMPLATE/ディレクトリに置きます。
- Markdownテンプレート(
bug_report.md) — あらかじめ埋められた本文を提供する単純な形式です。 - Issueフォーム(
bug_report.yml) — YAMLで定義する構造化された入力フォームです。テキスト入力、ドロップダウン、チェックボックスといったフィールドを強制でき、必須情報の欠落を防ぎます。
blank_issues_enabled: false
contact_links:
- name: 使い方の質問
url: https://github.com/example/repo/discussions
about: 質問はDiscussionsをご利用くださいconfig.ymlはテンプレート選択画面そのものを制御します。blank_issues_enabled: falseはテンプレートなしで空のIssueを開くことを防ぎ、contact_linksはIssueの代わりに案内する外部リンクを追加します。
通知 — Watchレベルと管理 #
リポジトリ右上のWatchボタンで通知レベルを選びます。
| レベル | 受け取る通知 |
|---|---|
| Participating and @mentions | 自分が参加したかメンションされた会話のみ(デフォルト) |
| All Activity | リポジトリのすべてのIssue、PR、リリース活動 |
| Ignore | メンションを含めて何も受け取らない |
| Custom | Issue、PR、リリースなど種類を選んで購読 |
通知はWebの通知ボックス(inbox)とメールで届き、個別のIssueやPR単位でもSubscribe/Unsubscribeを指定できます。繰り返し使うコメントがあるなら、saved repliesとして保存しておき、コメント入力欄から呼び出して使えます。
GitHub Flavored Markdown — コラボレーション画面で使う構造の文法 #
GFMの基本文法とメンション、参照は#2で整理しました。コラボレーションドメインでは、これに加えてIssueとPRの本文を構造化する文法が出題ポイントになります。
- [ ] 未完了タスク ← タスクリスト (Issueでチェックボックスとして表示)
- [x] 完了したタスク
| 列1 | 列2 | ← 表
| --- | --- |
```python ← コードフェンス (言語名でハイライト)
print("hello")
```
<details> ← 折りたたみ
<summary>タイトル</summary>
隠れた内容
</details>タスクリストは単なる表示ではなく、Issue本文に入れると進捗として集計され、PR本文ではチェックリストとして活用されます。このほかに取り消し線(~~テキスト~~)、脚注、絵文字表記(:tada:)もGFMの範囲です。
まとめ #
今回はコラボレーションドメインの前半として、Issueを中心とした作業トラッキング機能を整理しました。メンションと参照の区別、クローズキーワードの動作条件、テンプレートとフォームの違い、GFMの文法がこの領域の核心です。
次回の「GitHub Foundations #5 Domain 3-2: コラボレーション — Pull Request・コードレビュー・Discussions」では、コラボレーションドメインの後半として、Pull Requestのライフサイクルとコードレビュー、Issueとよく比較されるDiscussions、そしてGitHub Pagesまで整理します。