Day2 の座学「GitLab の基礎」の読み物です。Git や GitLab を初めて使う方が、後から読み返しても追えるように書いています。
バージョン管理と GitLab
基本
バージョン管理でできること
バージョン管理は、ファイルの変更を「いつ、誰が、何のために」と一緒に残す仕組みです。
| できること | 無いと困ること |
|---|---|
| 前の状態に戻せる | 壊した後に、どこまで戻せば動くのか分からない |
| 何人かで同じファイルを並行して直せる | 上書きし合って、誰かの直しが消える |
| 変更の理由が残る | 半年後に「なぜこの1行があるのか」を誰も説明できない |
| レビューしてから本線に入れられる | 確かめていない変更が、そのまま本番の元になる |
Git は、この履歴を自分の PC の中に持つ道具です。GitLab は、その履歴をチームで共有する置き場に、Issue(やること)、MR(変更の提案とレビュー)、CI/CD(自動の検査と実行)を一緒にしたものです。
言葉
GitHub との言葉の対応
| GitHub | GitLab | 中身 |
|---|---|---|
| repository | project | コードと履歴の置き場 |
| Organization | Group | project をまとめる単位。下にサブグループも作れる |
| Pull Request(PR) | Merge Request(MR) | 変更を本線に入れる提案。差分、議論、レビュー、パイプラインの結果が1か所に集まる |
Actions(.github/workflows/*.yml) | CI/CD(ルートの .gitlab-ci.yml) | push や MR のたびに自動で動く検査と処理 |
| runner | GitLab Runner | ジョブを実際に動かす機械。自社のサーバーに置ける |
| Secrets | CI/CD variables | API キーなどの秘密。ジョブのログでは伏せ字になる(masked) |
| Projects のボード | Issue boards | ラベルを列にして Issue を並べる |
Community Edition
Edition
Community Edition でできることと、できないこと
研修の GitLab は Community Edition(無料版)です。AI と一緒に開発する体制に要る機能の多くは入っていますが、承認の強制や AI の機能は有料版にあります。
| 機能 | CE | 研修での代わり |
|---|---|---|
| 保護ブランチ(main に直接 push させない) | ある | そのまま使う |
| パイプラインが通らないとマージできない | ある | そのまま使う |
MR のパイプライン、条件で動かすジョブ(rules) | ある | そのまま使う |
| スケジュールでパイプラインを動かす | ある | AI の実装サイクルに使う |
| CI/CD 変数(masked)、プロジェクトのアクセストークン | ある | AI 用のトークンを Developer に絞って使う |
Issue のラベルとボード、Closes #番号 で閉じる | ある | そのまま使う |
| 承認が何人要るかの強制、CODEOWNERS | 無い(Premium 以上) | マージできる人を Maintainer に絞る |
| push rules(ブランチ名やコミットの決まりの強制) | 無い(Premium 以上) | パイプラインのジョブで確かめる(レベル3) |
| GitLab Duo(GitLab の中の AI) | 無い(有料の追加) | Claude Code を CI のジョブで動かす |
Tips:無い機能は、パイプラインのジョブで代えられることが多いです。止める場所を GitLab の側に置く、という考え方は同じです。
コア機能
AI と開発するときに使う GitLab の機能
| 機能 | 今日の使い方 |
|---|---|
| Issue | やることと受け入れ条件を書く。人と AI が同じ文を読む |
| ラベルとボード | ai::approved で承認、ai::running と ai::done と ai::stopped で AI の進み具合を表す |
| MR | 差分、パイプライン、AI レビューを見て、人がマージを決める場所 |
| パイプライン | push と MR のたびに、構文、ルール、テスト、AI レビューを動かす |
| 保護ブランチとマージの条件 | main に直接入れさせない。パイプラインが緑でないとマージできない |
| CI/CD 変数 | API キーと AI 用のトークンを、リポジトリに書かずに渡す |
| スケジュール | 決まった時刻に AI の実装サイクルを動かす(午後は10分おき、夜は22時) |
| Runner | ジョブを自分たちで用意したサーバーで動かす(研修では研修用のサーバー)。コードが外に出るのは、AI に渡す分(Anthropic の API)だけ |
研修リポジトリ
リポジトリ
研修リポジトリの地図
dlive-training/dl-training-app は、中古 IT 機器の保守と販売を行う会社(演習用の架空の会社)の基幹システムです。PHP 7.4 で動く、見積と在庫の画面を持っています。
| 場所 | 中身 |
|---|---|
app/ | アプリの本体。app/core/ は触らない約束 |
db/ | スキーマと初期データ。触らない約束 |
tests/ | テスト。tests/phpunit/ に PHPUnit のテストを足す |
CLAUDE.md | Claude Code が毎回読む約束。55行、上限80行 |
docs/context/ | CLAUDE.md から @ で取り込む知識(PHP 7.4 の対応表) |
.claude/ | Claude Code の設定(settings.json)、フック、サブエージェント、スキル |
.githooks/ | コミットの前に動く git のフック |
.gitlab-ci.yml と ci/jobs/ | パイプラインの定義。ジョブは ci/jobs/ に種類ごとのファイルで置く |
ci/ | パイプラインが呼ぶスクリプト(AI レビュー、ゲート、AI の実装サイクル) |
.gitlab/issue_templates/ | AI に渡す Issue の型 |
docs/requests/ | 社内からの要望メモ(午後のレベル2の題材) |
docs/plan/ | 計画書の見本(プチ演習9 で使う) |
tools/ | 手元で使う道具(長さの検査、承認のレシート) |
Git の操作
操作
Git の操作と、するタイミング
| 操作 | 何をする | いつする |
|---|---|---|
git clone | GitLab のリポジトリを、手元にまるごと写す | 最初に1回 |
git switch ブランチ名 | 作業するブランチを切り替える | Issue の作業を始める前 |
git add | 次のコミットに入れる変更を選ぶ | コミットの直前 |
git commit | 手元の履歴に区切りを1つ残す。まだ自分の PC の中だけ | テストが通る単位で1歩進んだとき |
git push | 手元のコミットを GitLab のブランチに送る。パイプラインが動く | MR で見せたい所まで来たとき。席を離れる前 |
git fetch | GitLab の最新を取ってくるだけ。作業中のファイルは変わらない | 人の変更を見たいとき |
git pull | fetch したうえで、今のブランチに取り込む | main を最新にするとき |
| マージ(MR の画面) | ブランチの変更を main に入れる | パイプラインが緑で、人が読んで決めたとき |
コミットと push は別の操作です。 コミットしただけでは、GitLab には何も届かず、パイプラインも動きません。「コミットして、そのあと push」と、2つに分けて頼みます。
ブランチの決め事
- 1つの Issue に1つのブランチ、1つの MR
- ブランチは Issue の画面の Create merge request で作る。名前は Issue 番号から始まり(例
12-fmt-money-test)、MR と Issue が自動でつながる - 作業中の MR は Draft にしておく。Draft の MR はマージできない
- AI が作るブランチは
ai/issue-番号-…の形で、人のブランチと名前で見分けられる - main には直接 push できない(保護ブランチ)。main に入るのは、マージだけ
パイプライン
パイプライン
パイプラインの読み方
パイプラインは、段(stage)の順に、ジョブ(job)を動かします。同じ段のジョブは並んで動き、前の段が赤なら次の段は動きません。
| 段 | ジョブ | 動くとき |
|---|---|---|
| lint | lint-phpdev、lint-phpver、check-rules | push と MR |
| test | test、test-phpunit | push と MR |
| review | ai_review | MR のときだけ |
| gate | ai_gate | MR のときだけ |
| pick | ai_pick | AI の実装サイクル(変数 AI_CYCLE=on) |
| implement | ai_run と、その先の子パイプライン | AI の実装サイクル |
パイプラインが動くきっかけ
| きっかけ | 変数 CI_PIPELINE_SOURCE の値 |
|---|---|
| ブランチへの push | push |
| MR の作成と、MR があるブランチへの push | merge_request_event |
| スケジュール | schedule |
| 画面の Run pipeline | web |
どのジョブをどのきっかけで動かすかは、ジョブの rules に書きます。研修リポジトリでは、.gitlab-ci.yml の workflow:rules で、MR があるブランチへの push では MR のパイプラインだけを走らせています。ブランチ用と MR 用の2本に分かれると、「パイプラインが通らないとマージできない」が MR 用の1本しか見ず、ブランチ用で赤のテストがあってもマージできてしまうからです。
.gitlab-ci.yml の該当部分
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
when: never
- if: $CI_COMMIT_BRANCH
include:
- local: ci/jobs/*.yml用語
用語
用語
| 用語 | 意味 |
|---|---|
| Issue | やることを書いたチケット。受け入れ条件を書く |
| MR(Merge Request) | ブランチの変更を main に入れる提案 |
| Draft | 作業中の MR。マージできない |
| パイプライン | push や MR のたびに自動で動く、ジョブのまとまり |
| ジョブ | パイプラインの中の1つの処理 |
| Runner | ジョブを動かす機械 |
| 保護ブランチ | 直接 push できないブランチ。研修では main |
| Maintainer と Developer | プロジェクトでの役割。受講者は Developer で、マージは Maintainer(講師) |
| フック(Claude Code) | Claude がツールを使う前や後に動く検査。終了コード 2 で止める |
| フック(git) | コミットや push の前に手元で動く検査。--no-verify で飛ばせる |
