GitLabを活用したチーム開発で、Issueとコミット、マージリクエスト（MR）の連携に悩んでいませんか？
- チケット番号のないコミットが混在している
- MRにIssueが紐づいておらず目的が不明
- コミットメッセージのルールがメンバーごとにバラバラ
こうした課題を解決し、開発のトレーサビリティと品質を向上させるための運用ルール・テンプレート・自動化手法を、本記事では実務ベースで解説します。
1. GitLabプロジェクト設定：Issue機能の有効化
まずはプロジェクトでIssueが使える状態になっているか確認しましょう。
✅ 手順：
- プロジェクト画面を開く
- 左メニューから
Settings > Generalを選択 - “Visibility, project features, permissions” セクションを展開
IssuesをONに設定- 併せて
Merge requestsやRepositoryもONにしておくと便利（※Merge requestsを有効にすることでMRとIssueのリンクや自動クローズが可能になり、Repositoryを有効にすることでGit操作や履歴参照、コミット連携が機能します）
2. 命名ルールの統一運用
チームで一貫した命名ルールを使うことで、属人性を排除し、履歴管理が容易になります。
✅ ブランチ命名規則
| 種別 | 命名例 |
|---|---|
| 機能追加 | feature/123-login-form |
| バグ修正 | bugfix/456-fix-auth-error |
| 改善 | refactor/789-cleanup-code |
✅ コミットメッセージ構文
<カテゴリ>: <概要> Fixes #<Issue番号>
✅ 例：
feat: ログイン機能のエラーを修正 Fixes #101
feat: 商品検索画面に並び替え機能を追加 Fixes #202
refactor: 認証処理の構造を整理 Fixes #303
<カテゴリ>: <概要> #<Issue番号>
Fixes #<Issue番号>
✅ カテゴリ一覧
feat:新機能fix:バグ修正refactor:リファクタリングchore:設定ファイルなどdocs:ドキュメントtest:テスト
✅ MR命名ルール
| 項目 | 内容 |
|---|---|
| タイトル | Issueタイトルと同一 |
| 説明 | Fixes #123 などを明記 |
| ラベル | type:feature, type:bugfix 等 |
3. コミットテンプレートの自動化（.gitmessage）
🪟 Windowsの場合：
- ホームディレクトリ：
C:\\Users\\<ユーザー名> - 推奨ファイル名：
.gitmessage.txt - 例：
C:\\Users\\User\\.gitmessage.txt
🐧 Linux / 🐱 macOSの場合：
- ホームディレクトリ：
/home/<ユーザー名>または/Users/<ユーザー名> - 推奨ファイル名：
.gitmessage - 例：
~/.gitmessage
毎回手動でメッセージを書くのは手間です。テンプレートを自動挿入しましょう。
✅ 設定手順
~/.gitmessageファイルを作成<type>: <subject> #<Issue番号> <body> Fixes #<Issue番号>- 以下を実行
git config --global commit.template ~/.gitmessage
4. Visual Studioでテンプレートを使うには？（補足）
Visual StudioのGUIでは.gitmessageテンプレートは反映されませんが、以下のようにターミナルを併用すれば活用可能です。
✅ 実装手順
C:\\Users\\<ユーザー名>\\.gitmessage.txtを作成- Git BashやVSのターミナルで以下を設定
git config --global commit.template "C:\\\\Users\\\\<ユーザー名>\\\\.gitmessage.txt" - ターミナルで
git commitを実行 → テンプレートが表示される
❗ 注意点
- Visual Studioの[変更]ウィンドウではテンプレートは表示されない
- CIでのコミット検査と組み合わせるとGUIユーザーの品質も確保可能
5. コミットメッセージとIssue連携の基本
コミットメッセージに特定のキーワードとIssue番号を含めることで、GitLabが自動的にIssueをクローズしたり、関連付けたりします。
✅ 構文例：
git commit -m "fix: ログインエラー修正 Fixes #101"
✅ 利用可能キーワード
| キーワード | 動作 |
|---|---|
| Fixes #123 | 自動クローズ（マージ時にIssueが閉じられる） |
| Closes #123 | 同上 |
| Resolves #123 | 同上 |
| Related to #123 | 関連付けのみ（クローズはされない） |
| Addresses #123 | 関連付けのみ（作業中・対応中の意味合い） |
| Implements #123 | 実装内容を関連付ける（リリース時にクローズ判断） |
| Refs #123 | リファレンスとしてIssueに言及（影響を与えるが未完） |
補足： Fixes などを使うと自動でIssueがクローズされますが、例えば「リリースをもって完了としたい」などの運用方針がある場合は、Implements #123 や Addresses #123 を使用して関連付けのみに留め、手動でクローズするのが適しています。 関連づけのみ |
✅ Visual Studioからの連携について
Visual Studioの[変更]ウィンドウからのコミットでも、以下のように 正しいキーワード付きでメッセージを記述すればGitLabはIssueと連携します。
Fixes #123：自動でIssueをクローズします。#123のみ：Issueへのリンクは生成されますが、自動クローズはされません。fix: #123：無効です。必ずFixesやClosesを使ってください。
✅ 例（Visual Studioからも有効）：
fix: ログイン処理の修正 Fixes #123
GUI中心の開発環境でも、正しい書式でIssueとのトレーサビリティが保たれます。 関連づけのみ |
6. MRとIssueの連携ルール
マージリクエストでもIssue番号を指定することで、マージ完了と同時にIssueを自動クローズできます。
✅ MR説明欄の記述例
このMRは以下のIssueを解決します：
Fixes #456
※注意：Squashマージ時は、MRタイトルや本文にキーワードが必要です。コミット本文だけではクローズされません。
7. .gitlab-ci.ymlによるコミット検査の自動化
ルール違反を防ぐにはCIで検査するのが効果的です。
✅ 例：Issue番号の有無チェック
stages:
- check
- test
check_commit_message:
stage: check
script:
- |
if ! echo "$CI_COMMIT_MESSAGE" | grep -Eq "#[0-9]+"; then
echo "コミットメッセージにIssue番号が含まれていません。形式：fix: 説明 Fixes #123"
exit 1
fi
only:
- merge_requests
8. マージ戦略とSquash連携
GitLabには以下のようなマージ戦略があります。状況に応じて選択しましょう。
✅ 各戦略の特徴
- Fast-forward only：履歴が直線的。小規模向き
- Merge commit：履歴にMR単位が残る。大規模向き
- Squash and merge：履歴が整理され、ログが見やすい
✅ 推奨運用例（Squashあり）
feat: 商品検索に並び替え機能を追加 #789
Fixes #789
※MR本文やタイトルに Fixes #789 が含まれていれば、自動的にクローズされます。
まとめ
本記事では、GitLabを用いたIssueとコミット連携を実務で運用するためのノウハウを網羅しました。
- プロジェクト設定による機能有効化
- 命名ルールとテンプレートの統一
- コミットとMRによるIssue自動クローズ
.gitlab-ci.ymlでの自動チェック- マージ戦略と連携のベストプラクティス
まずは .gitmessage と .gitlab-ci.yml の導入から始め、段階的にルールをチームに浸透させましょう。自動化と視覚化こそが、スケーラブルな開発体制の鍵です。
コメント