Gitのチケット管理｜GitLab・GitHub・Jiraでコミットとイシューを紐づける書き方

Gitでチケット管理をするときの基本は、コミットメッセージやプルリクエスト（マージリクエスト）の説明に「Closes #123」や「PROJ-123」のようにチケット番号を書くことです。GitHubとGitLabはその番号でイシューとコードを自動で結び付け、デフォルトブランチにマージされた時点でイシューを閉じます。

この記事では、GitLab・GitHub・Jiraそれぞれで「どう書けば紐づくのか」「いつ自動で閉じるのか」を公式ドキュメント（2026年10月14日確認）にもとづいて比べ、チームで番号の書き忘れを防ぐ仕組みまで実際に動かして説明します。Git自体の基本コマンドはgit コマンド早見表を参照してください。

チケット管理とGitを結び付ける理由

チケット（イシュー、課題、作業項目とも呼びます）は「何を・なぜ直すか」の記録で、Gitのコミットは「どう直したか」の記録です。この2つが番号でつながっていると、次のことができるようになります。

• コードの1行から、そこを変えた理由（元のバグ報告や要望）までたどれる
• チケットの画面から、対応中のブランチやプルリクエストが見える
• マージしたらチケットが自動で閉じるので、「直したのに未完了のまま」が減る
• リリースごとに、どのチケットが入ったかをコミット履歴から集計できる

GitHub・GitLab・Jiraの書き方を比べる

項目	GitHub Issues	GitLab Issues	Jira（Smart Commits）
番号の書き方	#123、別リポジトリは owner/repo#123	#123、別プロジェクトは group/project#123、イシューのURLも可	PROJ-123（キー＋番号）
閉じるキーワード	close / closes / closed / fix / fixes / fixed / resolve / resolves / resolved	Close・Fix・Resolve・Implement の各活用形（Closing、Implements なども可）	#close や #resolve など、ワークフローの遷移名
書く場所	プルリクエストの説明、またはコミットメッセージ	マージリクエストの説明、またはコミットメッセージ	コミットメッセージ（ブランチ名やPRタイトルのキーでも連携表示）
閉じるタイミング	デフォルトブランチにマージされたとき	デフォルトブランチにプッシュ、またはマージされたとき	コミットが連携先で処理されたとき
その他のコマンド	なし（手動リンクはサイドバーの Development から）	なし（「Related to #5」は関連付けのみで閉じない）	#comment でコメント、#time で作業時間の記録

出典：GitHub「Linking a pull request to an issue」、GitLab「Manage issues」、Atlassian「Process work items with smart commits」（いずれも2026年10月14日確認）。

GitLabでのチケット管理

Closes #番号 でイシューを自動で閉じる

GitLabでは、コミットメッセージかマージリクエストの説明に「closing pattern」と呼ばれる語を書くと、参照したイシューが自動で閉じます。たとえばマージリクエストの説明に次のように書きます。

Closes #4, #6, Related to #5

公式ドキュメントの例どおり、マージ時に #4 と #6 は閉じ、#5 は関連イシューとして記録されるだけで閉じません。閉じる語は Close・Fix・Resolve・Implement の各活用形（Closes、Fixed、Resolving、Implements など）で、大文字始まりでも小文字でも使えます。

自動で閉じないときに確認すること

• マージ先がデフォルトブランチ（多くは main）か。develop など別のブランチへのマージでは閉じません
• プロジェクトの設定で無効になっていないか。Settings > Repository > Branch defaults の「Auto-close referenced issues on default branch」で切り替えます（Maintainer 以上）
• 既存リポジトリを初めてプッシュしたときは、性能上の理由で自動クローズが働きません
• マージする人に、そのイシューを閉じる権限があるか

イシューボードでカンバン管理する

GitLabのイシューボードは、ラベルやマイルストーンごとの列にイシューのカードを並べ、ドラッグで状態を動かせる画面です。公式ドキュメント「Issue boards」によると、プロジェクトのボードは Free を含む全プランで複数作れますが、グループのボードを複数作る機能や、設定を保存できるボード（Configurable issue boards）は Premium 以上です（2026年10月14日確認）。「未着手」「対応中」「レビュー待ち」のようなラベルを先に決め、それを列にするのが基本の使い方です。

GitHubでのチケット管理

プルリクエストの説明に Closes #番号 を書く

GitHubでは、プルリクエストの説明かコミットメッセージに「Closes #10」のように書くと、そのプルリクエストがデフォルトブランチにマージされた時点でイシューが閉じます。公式ドキュメントでは、キーワードのあとにコロンを付けたり大文字にしたりしても（Closes: #10、CLOSES #10）認識されると説明されています。複数のイシューを閉じるときは「Resolves #10, resolves #123」のように、1件ずつキーワードを付けます。

注意点は2つです。プルリクエストのマージ先がデフォルトブランチ以外だとキーワードは無視されます。また、コミットメッセージにキーワードを書いた場合もイシューは閉じますが、そのプルリクエストは「リンク済み」として表示されません。チームでは「プルリクエストの説明に書く」とそろえておくと、イシュー側から追いやすくなります。

イシューからブランチを作る・サブイシューで分ける

イシュー画面右側の「Development」から、そのイシュー用のブランチを作成できます（公式ドキュメントでは public preview と記載）。このブランチからプルリクエストを作ると、自動でイシューに紐づきます。大きな作業は、サブイシュー（sub-issues）で親イシューの下に分割でき、進み具合を GitHub Projects のビューで親イシューごとにまとめて見られます。

イシューのテンプレートとフォーム

バグ報告の書き方をそろえるには、リポジトリの .github/ISSUE_TEMPLATE/ フォルダにテンプレートを置きます。YAMLで書く「issue forms」を使うと、入力欄・選択肢・チェックボックスを持つフォーム形式にでき、再現手順や環境の書き漏れを減らせます（Configuring issue templates for your repository、2026年10月14日確認。issue forms は public preview）。

JiraとGitを連携するSmart Commits

Jira（Jira Software）は、課題を「作業項目（work item）」、プロジェクトを「スペース」と呼ぶようになっています。GitやGitHub・Bitbucketと連携すると、コミットメッセージに作業項目のキーとコマンドを書いて Jira を操作できます。これが Smart Commits です。

PROJ-123 #comment ログイン画面の文言を修正
PROJ-123 #time 2d 5h 調査とテスト
PROJ-123 #time 2d 5h #comment 予定より早く完了 #resolve

• #comment：作業項目にコメントを追加します
• #time：作業時間を記録します（Jira側で時間管理が有効になっている必要があります）
• #遷移名：#close、#resolve、#in-progress のように、ワークフローの状態を移します。遷移名にスペースがある場合はハイフンでつなぎます

Atlassianのドキュメントでは、1つのコマンドを複数行にまたがって書けないこと、コミットしたメールアドレスが Jira のユーザーと一致している必要があることが明記されています。GitLabを使っている場合も、GitLabのJira連携（Jira development panel）を設定すれば同じ書式の Smart Commits が使えます。

チケット番号の書き忘れをGitのフックで防ぐ

番号の紐づけは、書き忘れが1回あるだけで履歴が途切れます。ローカルのGitには、コミットの直前にメッセージを検査できる commit-msg フックがあります。次のファイルを .git/hooks/commit-msg に置いて実行権限を付けると、番号のないコミットを止められます。

#!/bin/sh
# .git/hooks/commit-msg
# コミットメッセージにチケット番号（#123 または PROJ-123）がなければ止める
if ! grep -qE '(#[0-9]+|[A-Z][A-Z0-9]+-[0-9]+)' "$1"; then
  echo "エラー: コミットメッセージにチケット番号（例: #123 / PROJ-123）を入れてください" >&2
  exit 1
fi

一時フォルダに新しいリポジトリを作り、このフックを入れて試した手順と結果です（Git 2.50.1 で実行）。

rm -rf demo && mkdir demo && cd demo
git init -q -b main
git config user.name demo && git config user.email demo@example.com
cp ../hook.sh .git/hooks/commit-msg && chmod +x .git/hooks/commit-msg

echo a > a.txt && git add a.txt
git commit -q -m "ログイン画面を修正" || echo "→ コミットは中止されました"
git commit -q -m "fix: ログイン画面の文言を修正 (#123)" && echo "→ コミットできました"

git switch -q -c feature/PROJ-45-csv-export
echo b > b.txt && git add b.txt
git commit -q -m "PROJ-45 CSV出力を追加 #comment 文字コードはUTF-8"
echo c >> b.txt
git commit -q -am "PROJ-45 #time 1h 30m テストを追加"
git log --format='%s' main..HEAD

実行結果：

エラー: コミットメッセージにチケット番号（例: #123 / PROJ-123）を入れてください
→ コミットは中止されました
→ コミットできました
PROJ-45 #time 1h 30m テストを追加
PROJ-45 CSV出力を追加 #comment 文字コードはUTF-8

番号のない1回目のコミットだけが止められ、#123 や PROJ-45 を含むコミットは通りました。ブランチ名にもキーを入れておくと（feature/PROJ-45-csv-export）、Jira の開発パネルなどでブランチも作業項目に紐づけて表示されます。なお .git/hooks の中身はリポジトリと一緒に共有されないので、チームで使うときは各自が入れるか、サーバー側（GitHub や GitLab のプッシュルール、CIのチェック）で同じ検査を行います。

コミット履歴からチケットごとに集計する

番号の書き方がそろっていれば、リリース前に「どのチケットに何件のコミットがあるか」をスクリプトで集計できます。上のデモのリポジトリに対して Python で実行した例です。

import re
import subprocess
from collections import defaultdict

# 直近のコミットの件名を取得し、チケット番号ごとにまとめる
log = subprocess.run(
    ["git", "log", "--all", "--format=%h %s"],
    cwd="demo", capture_output=True, text=True, check=True,
).stdout

pattern = re.compile(r"#\d+|\b[A-Z][A-Z0-9]+-\d+\b")
by_ticket = defaultdict(list)
for line in log.splitlines():
    sha, subject = line.split(" ", 1)
    for ticket in pattern.findall(subject):
        by_ticket[ticket].append(sha)

for ticket, shas in sorted(by_ticket.items()):
    print(ticket, len(shas), "件")

実行結果：

#123 1 件
PROJ-45 2 件

正規表現で #番号 と PROJ-番号 の両方を拾っています。リリースノートの下書きや、対応漏れの確認に使えます。

チームで決めておきたい運用ルール

• チケットのないコミットを作らない（小さな修正も、まとめ用のチケットに紐づける）
• ブランチ名は「種類/番号-内容」にそろえる（例：feature/123-login、fix/PROJ-45-csv）
• 閉じるキーワードはプルリクエスト（マージリクエスト）の説明に書く。途中のコミットには番号だけを書く
• 「Related to」「refs」など閉じない書き方と、「Closes」など閉じる書き方を使い分ける
• ラベルは種類（bug、feature など）と状態（対応中、レビュー待ち）を分けて、増やしすぎない

コミットメッセージの書式まで統一したい場合は、Conventional Commits のような公開された規約（feat: や fix: で始める書き方）を採用すると、説明の手間が省けます。

よくある質問

Q. GitLabでコミットにイシュー番号を書いても閉じないのはなぜですか？

マージ先がデフォルトブランチでない、プロジェクトで自動クローズが無効になっている、Closesなどの閉じる語がない、のいずれかが多い原因です。Related toのような書き方は関連付けだけで閉じません。

Q. GitHubで1つのプルリクエストから複数のイシューを閉じられますか？

はい。Resolves #10, resolves #123 のように、イシューごとにキーワードを付けて書きます。マージ先がデフォルトブランチである必要があります。

Q. Jiraのチケットをコミットから完了にできますか？

Smart Commitsで、PROJ-123 #close のようにワークフローの遷移名を書くと状態を移せます。コミットしたメールアドレスがJiraのユーザーと一致し、その操作の権限があることが条件です。

Q. チケット管理はGitHubとGitLabのどちらが向いていますか？

コードを置いている場所に合わせるのが基本です。番号の紐づけと自動クローズはどちらにもあり、GitLabはイシューボードやマージリクエストとの連携を同じ画面で扱えます。スクラムの細かな管理や他部署との共有が必要ならJiraと連携する形もあります。

まとめ

Gitのチケット管理は、ツールの機能より「番号を必ず書く」「閉じる語を正しく書く」というルールで決まります。GitLabとGitHubは Closes #番号 をデフォルトブランチへのマージで処理し、Jiraは Smart Commits でコメント・時間・状態をまとめて操作できます。書き忘れはフックやCIで機械的に止め、集計はコミット履歴から行うと、チームの規模が大きくなっても運用が崩れにくくなります。環境構築やエディタを含めた全体像はGitと開発環境の基礎にまとめています。