プロジェクトの作成、管理、公開設定、プロジェクト設定、説明テンプレート

(トップページはこちら) - (プロジェクトで作業を整理する)

「Issueの書き方がバラバラで、必要な情報が抜けている」「古いプロジェクトが放置されて管理が煩雑になっている」「チーム全体で統一されたワークフローを確立したい」

こうした課題は、GitLabのプロジェクト管理機能を適切に活用することで解決できます。本記事では、プロジェクトの作成から日常運用、そしてライフサイクル管理まで、実践的な機能とその活用方法を解説します。

1. プロジェクトの作成と初期設定

1.1 目的に応じた作成方法の選択

GitLabでは3つのプロジェクト作成方法が用意されています。

ブランクプロジェクトは、完全にゼロから始めたい場合に適しています。左サイドバーの新規作成から新規プロジェト/リポジトリを選択し、以下を設定します。

プロジェクト名: プロジェクトの識別名
プロジェクトスラッグ: URLパスとして使用されるパス名
公開レベル: PrivateまたはPublicを選択
READMEで初期化: リポジトリの初期化（推奨）
SAST有効化: セキュリティスキャンの有効化
シークレット検出: 認証情報漏洩の防止

組み込みテンプレートは、一般的なプロジェクト構成をすぐに利用したい場合に便利です。Ruby on Rails、Node.js、Pythonなどの言語別テンプレートや、GitLab Pagesテンプレートが用意されています。医療関連プロジェクトでは、HIPAA監査プロトコルテンプレートも利用できます。

カスタムテンプレート（Premium/Ultimate）は、組織固有の標準構成を再利用する場合に使用します。グループレベルで設定することで、チーム全体で統一されたプロジェクト構造を維持できます。

1.2 セキュリティを重視する場合：SHA-256ハッシュ

連邦規制やセキュリティ要件が厳しい環境では、SHA-256ハッシュアルゴリズムを使用したプロジェクトを作成できます。これは実験的機能ですが、NIST/CISAガイドラインやFedRamp要件に対応する必要がある場合に有効です。

重要な制約:

プロジェクト作成時のみ選択可能（後から変更不可）
40文字のコミットIDが64文字になる
2030年までにSHA-1廃止が予定されている連邦規制への対応

1.3 公開レベルの設定

GitLab.comでは、PrivateとPublicの2つの公開レベルがあります。

Privateプロジェクトは、メンバーのみがアクセス可能です。Guestロールはクローンできません。社内プロジェクトや機密情報を扱う場合はこちらを選択します。

Publicプロジェクトは、未認証ユーザーを含むすべてのユーザーがアクセス可能です。オープンソースプロジェクトやドキュメントサイトに適しています。

2. プロジェクトの日常運用

2.1 プロジェクト情報の把握

プロジェクト概要ページでは、以下の情報を一目で確認できます。

リポジトリ内のファイルとREADME
スター数、フォーク数、コミット数、ブランチ数
プロジェクトストレージサイズ
CI/CD設定、統合機能、GitLab Pagesの状態
プロジェクト作成日

プロジェクトIDの確認は、API利用時に必要です。プロジェクト概要ページ右上のアクションメニューからプロジェクトIDをコピーを選択します。IDを使ったアクセスも可能です。

https://gitlab.com/projects/<id>
https://gitlab.com/-/p/<id> (GitLab 17.5以降)

2.2 効率的なプロジェクト検索

プロジェクト一覧では、以下のタブで効率的にフィルタリングできます。

Contributed: 自分が貢献したプロジェクト（Issue作成、コメント、コミット、マージリクエスト承認など）
Starred: スターを付けたプロジェクト（頻繁に使うプロジェクトに便利）
Personal: 個人ネームスペース配下のプロジェクト
Member: メンバーとして参加しているプロジェクト
Inactive: アーカイブ済みまたは削除予定のプロジェクト

プログラミング言語でのフィルタリングも可能です。「Rubyのプロジェクトだけ見たい」といった場合に、検索またはフィルタ結果から言語ドロップダウンリストで絞り込めます。

2.3 プロジェクトアクティビティの追跡

管理 > アクティビティから、プロジェクトの活動状況を確認できます。

プッシュイベント: コードの変更履歴
マージイベント: 承認されたマージリクエスト
Issueイベント: 開かれたIssueとクローズされたIssue
コメント: ディスカッションの活発度
チーム: メンバーの参加と離脱

注意: パフォーマンス上の理由から、3年以上前のアクティビティイベントは自動削除されます。長期的な履歴が必要な場合は、別途記録を保持してください。

3. プロジェクト設定のカスタマイズ

3.1 機能の有効化と無効化

設定 > 一般 > 公開レベル、プロジェクト機能、権限から、プロジェクトで使用する機能を個別に制御できます。

機能の依存関係に注意してください。

Issueを無効化すると、Issue BoardsとService Deskも使用不可になります
IssueとMerge Requestsを無効化すると、LabelsとMilestonesも使用不可になります
Repositoryを無効化すると、Merge requests、CI/CD、Git LFS、Packagesも使用不可になります

例えば、ドキュメント専用プロジェクトでは、RepositoryとWikiのみを有効化し、IssueやCI/CDを無効化することで、シンプルな構成を維持できます。

3.2 マージリクエストの標準化

設定 > マージリクエストから、チーム全体のマージフローを統一できます。

推奨設定:

マージ時にソースブランチを削除をデフォルト有効化（ブランチの肥大化を防止）
パイプライン成功時のみマージを有効化（品質保証）
すべてのスレッド解決時のみマージを有効化（レビューの徹底）

これらの設定により、「マージ後にブランチが残ったまま」「テストが失敗しているのにマージされた」といった問題を防げます。

3.3 メール通知の最適化

設定 > 一般 > 公開レベル、プロジェクト機能、権限から、メール通知を制御できます。

差分プレビューを含める設定は、セキュリティポリシーに応じて調整してください。組織によっては、メールシステムのセキュリティレベルが低い場合があり、コード差分をメールで送信することがリスクになる可能性があります。

4. 説明テンプレートによる標準化

説明テンプレートは、IssueやMerge Requestの品質を向上させる最も効果的な機能の一つです。

4.1 テンプレートの作成

Issueテンプレートを作成するには、.gitlab/issue_templates/ディレクトリに.mdファイルを配置します。

例えば、バグレポート用テンプレート（.gitlab/issue_templates/bug.md）を作成すると、Issue作成時にテンプレートを選択ドロップダウンリストに表示されます。

Merge Requestテンプレートも同様に、.gitlab/merge_request_templates/ディレクトリに配置します。

4.2 実践的なテンプレート例

バグレポートテンプレート:

## 概要

（発生したバグを1〜2文で要約してください）

## 環境

- ブラウザ: 
- OS: 
- バージョン: 

## 再現手順

1. 
2. 
3. 

## 期待される動作

（本来どうあるべきか）

## 実際の動作

（実際に何が起こるか）

## スクリーンショット

（可能であれば添付してください）

## 追加情報

（エラーログ、コンソール出力など）

/label ~bug ~needs-investigation
/cc @team-lead

機能リクエストテンプレート:

## 機能の概要

（実現したい機能を簡潔に説明してください）

## 背景と課題

（なぜこの機能が必要なのか）

## 提案する解決策

（どのように実装するか）

## 代替案

（他に検討した方法があれば）

## 影響範囲

（この機能が影響する範囲）

/label ~feature ~discussion

4.3 Merge Requestテンプレートの変数活用

デフォルトテンプレートでは、以下の変数を使用して自動的に情報を埋め込めます。

## 変更内容

%{first_multiline_commit}

## コミット一覧

%{all_commits}

## 共同作成者

%{co_authored_by}

## ブランチ情報

- ソースブランチ: %{source_branch}
- ターゲットブランチ: %{target_branch}

これにより、マージリクエスト作成時に手動で情報を入力する手間が省けます。

4.4 グループレベルテンプレート（Premium/Ultimate）

複数のプロジェクトで同じテンプレートを使用する場合、グループレベルで設定できます。

グループの設定 > 一般 > テンプレートを選択
テンプレートを保存したプロジェクトを選択
変更を保存を選択

これにより、グループ内のすべてのプロジェクトで同じテンプレートが利用可能になります。

4.5 デフォルトテンプレートの設定

すべてのIssueやMerge Requestに自動的にテンプレートを適用したい場合、以下の方法があります。

方法1: Default.mdファイルを作成（すべてのプラン）

.gitlab/issue_templates/Default.md
.gitlab/merge_request_templates/Default.md

方法2: プロジェクト設定で指定（Premium/Ultimate）

設定 > 一般 > Issueのデフォルト説明テンプレート
設定 > マージリクエスト > マージリクエストのデフォルト説明テンプレート

優先順位は以下の通りです。

プロジェクト設定で指定したテンプレート（最優先）
親グループのDefault.md
プロジェクトリポジトリのDefault.md

5. プロジェクトのライフサイクル管理

5.1 プロジェクトのアーカイブ

アーカイブは、プロジェクトを削除せずに非アクティブ化する安全な方法です。監査要件やコンプライアンスのために履歴を保持する必要がある場合に適しています。

アーカイブ時の変更:

プロジェクトが読み取り専用になる
Archivedバッジが表示される
フォーク関係が削除され、フォークからのMerge Requestがクローズされる
デプロイされたPagesが削除される
スケジュールされたCI/CDパイプラインが停止する
プルミラーリングが停止する

アーカイブ手順:

設定 > 一般 > 詳細設定を選択
プロジェクトをアーカイブセクションでアーカイブを選択

または、プロジェクト一覧から直接アーカイブすることもできます。

検索または移動 > すべてのプロジェクトを表示を選択
Memberタブでプロジェクトを見つけ、アクションメニュー（︙）を選択
アーカイブを選択

5.2 プロジェクトのアーカイブ解除

アーカイブ解除すると、読み取り専用制限が解除され、スケジュールされたパイプラインとプルミラーリングが自動的に再開されます。

重要: デプロイされたPagesは自動的に復元されません。Pagesを復元するには、パイプラインを手動で再実行する必要があります。

アーカイブ解除手順:

検索または移動 > すべてのプロジェクトを表示 > Inactiveタブを選択
プロジェクトを見つけ、設定 > 一般 > 詳細設定を選択
プロジェクトをアーカイブ解除セクションでアーカイブ解除を選択

5.3 プロジェクトの削除と復元

GitLab 18.0以降、デフォルトで遅延削除が有効になっています。これにより、誤って削除した場合でも復元できます。

削除手順:

設定 > 一般 > 詳細設定を選択
プロジェクトを削除セクションで削除を選択
確認ダイアログでプロジェクト名を入力し、はい、プロジェクトを削除しますを選択

削除の動作:

GitLab.comでは30日後に完全削除される
削除をスケジュールしたユーザーがアクセス権を失った場合、削除ジョブは自動的にプロジェクトを復元する

復元手順:

検索または移動 > すべてのプロジェクトを表示 > Inactiveタブを選択
削除予定のプロジェクトを見つけ、設定 > 一般 > 詳細設定を選択
プロジェクトを復元セクションでプロジェクトを復元を選択

注意: GitLab.comでは、即時削除は利用できません。即時削除が必要な場合は、サポートチケットを開く必要があります。

5.4 プロジェクトの転送

プロジェクトを別のグループに移動する場合、以下の点に注意してください。

転送に含まれるもの:

プロジェクトコンポーネント（Issue、Merge Request、パイプライン、ダッシュボード）
直接メンバーとメンバーシップ招待

転送時の注意点:

プロジェクトパスが変更されるため、URLの更新が必要
継承メンバーシップは失われる（ターゲットグループのメンバーシップを新たに継承）
一致するグループラベルがない場合、新しいプロジェクトレベルラベルが作成される
Issueが割り当てられたEpicは、ターゲットグループにコピーされる

前提条件:

転送先グループのMaintainerロール以上
転送元プロジェクトのOwnerロール
グループで新規プロジェクト作成が許可されている
Container Registryが有効な場合、同じトップレベルネームスペース内のみ転送可能
セキュリティポリシーが割り当てられていない
npmパッケージの命名規則に従っている場合、ルートネームスペースが変更される場合は削除が必要

転送手順:

設定 > 一般 > 詳細設定を選択
プロジェクトを転送セクションで、転送先のネームスペースを選択
プロジェクトを転送を選択
確認ダイアログでプロジェクト名を入力し、確認を選択

6. 実践のためのチェックリスト

GitLabプロジェクト管理を効果的に活用するために、以下のチェックリストを参考にしてください。

6.1 プロジェクト作成時

適切な公開レベル（Private/Public）を選択した
READMEで初期化を有効にした
セキュリティスキャン（SAST、シークレット検出）を有効にした
プロジェクト説明を記入した

6.2 初期設定時

不要な機能を無効化した
マージリクエスト設定を確認した（ソースブランチ削除、パイプライン成功時のみマージなど）
メール通知設定を確認した
プロジェクトアバターを設定した

6.3 テンプレート設定時

バグレポート用Issueテンプレートを作成した
機能リクエスト用Issueテンプレートを作成した
Merge Requestテンプレートを作成した
デフォルトテンプレートを設定した（必要に応じて）

6.4 日常運用時

頻繁に使うプロジェクトにスターを付けた
プロジェクトアクティビティを定期的に確認している
不要になったプロジェクトをアーカイブした
3年以上前のアクティビティが削除されることを認識している

6.5 ライフサイクル管理時

削除前にアーカイブを検討した
削除後30日以内であれば復元可能であることを認識している
プロジェクト転送時の影響範囲を確認した
転送後のURL変更をチームに通知した

7. まとめと次のステップ

GitLabのプロジェクト管理機能を活用することで、以下の効果が期待できます。

標準化されたワークフロー: テンプレートにより、IssueやMerge Requestの品質が向上
効率的なプロジェクト検索: フィルタリング機能により、必要なプロジェクトにすぐアクセス
安全なライフサイクル管理: アーカイブと遅延削除により、誤操作のリスクを軽減
柔軟な設定: プロジェクトごとに機能を有効化/無効化し、最適な構成を実現

今日から始められるアクション:

既存プロジェクトにバグレポート用Issueテンプレートを1つ作成する
頻繁に使うプロジェクトにスターを付ける
使われていないプロジェクトをアーカイブする
マージリクエスト設定でソースブランチ削除をデフォルト有効化する

これらの小さな改善を積み重ねることで、チーム全体の生産性が向上します。GitLabのプロジェクト管理機能を最大限に活用し、効率的な開発環境を構築してください。