---
title: "GitLabの使い方：プロジェクト作成からIssue・MR・CI/CDまでの手順【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/18874/"
published: 2026-10-25
updated: 2026-10-25
categories: ["開発"]
publisher: "株式会社一創"
---

# GitLabの使い方：プロジェクト作成からIssue・MR・CI/CDまでの手順【2026年10月】

GitLabの使い方を、プロジェクトを1つ作ってIssueを起票し、マージリクエスト（MR）でレビューしてmainへ取り込み、CI/CDのパイプラインを1本動かすところまで、作業の順番どおりに解説します。日本語化やSSH鍵の登録といった最初のつまずきどころも、公式ドキュメントの該当ページへのリンクとコピーして使えるコマンドで押さえました。後半では、Freeプランの上限やマージの承認の扱いをもとに、チームでGitLabを採用するかの判断基準も示します。画面名・数値は2026年10月時点のGitLab.com（19.5系）で確認したものです。

## まとめ：GitLabの使い方は「Issue→ブランチ→MR→CI」の1周で覚える

GitLabは、Gitリポジトリに加えてIssue（課題管理）、マージリクエスト（レビュー）、CI/CD（自動ビルド・テスト）を1つのプロジェクトの中で扱えるサービスです。機能が多いので、画面を1つずつ覚えるより、Issueを1件起票してからMRでクローズされるまでを一度通すほうが早く全体像がつかめます。

最初の1周で設定しておくのは5つだけです。表示言語の日本語化、SSH鍵の登録、READMEつきの空プロジェクト作成、Issueからのブランチ作成、ルートに置く`.gitlab-ci.yml`。この5つが済めば、日々の作業は「Issueを選ぶ→MRを作る→パイプラインが緑になったらマージ」の繰り返しになります。

導入判断で見落としやすいのは、GitLab.comのFreeプランではMRの承認が「任意」で、承認なしでもマージできる点です。レビューを必須にしたいチームはPremium以上か、保護ブランチの権限設計で補う必要があります。

## GitLab導入前の選択：GitLab.comとSelf-Managed・Freeの範囲

### GitLab.comとSelf-Managedの違いと19.5系の保守期間の数え方

GitLabには、GitLab社がホストするGitLab.com（SaaS）と、自社のサーバーに入れて運用するSelf-Managedがあります。アカウントを作ればすぐ使えるのはGitLab.comで、本記事の手順もこちらを前提にしています。

Self-Managedを選ぶと、バージョンアップの責任は自社に移ります。[GitLabのリリースと保守のポリシー](https://docs.gitlab.com/policy/maintenance/)では、マイナー版は毎月第3木曜に出て、2026年10月時点の保守対象は19.5（不具合とセキュリティ修正）、19.4と19.3（セキュリティ修正のみ）の3つです。つまり3か月更新を止めると、セキュリティ修正すら届かない版になります。

実際にクリティカルな修正が出たときの対応手順は[GitLab脆弱性の対応手順と修正版への更新の判断基準](https://www.issoh.co.jp/tech/details/18332/)で扱っています。サーバー保守の人手が無いなら、迷わずGitLab.comから始めてください。

### Freeプランの5ユーザー・月400分・10GiBの上限と超えたときの費用

[GitLabの料金ページ](https://about.gitlab.com/pricing/)によると、GitLab.comのFreeは「トップレベルグループあたり5ユーザー」「月400分のcompute minutes（CI実行時間）」「10GiBのストレージ」が上限です。Premiumは1ユーザー月29ドル（年払い）で、計算分数は月10,000分に増えます。

| 項目       | Free      | Premium      |
| -------- | --------- | ------------ |
| 料金       | 0ドル       | 月29ドル／人（年払い） |
| ユーザー数    | グループあたり5人 | 上限なし         |
| CI計算分数   | 月400分     | 月10,000分     |
| ストレージ    | 10GiB     | 500GiB       |
| MR承認の必須化 | 不可（任意のみ）  | 可能           |

CIの分数が足りなくなった場合は、1,000分あたり10ドルの追加購入で補えます。6人目を招待する時点でFreeは使えなくなるため、人数が先に上限へ届くチームが多いはずです。

## GitLabの初期設定：日本語化・SSH鍵登録・空のプロジェクトへの初回push

### 表示言語を日本語に切り替えるLocalizationタブの設定手順

GitLabの画面は英語が既定ですが、ユーザーごとに日本語へ切り替えられます。[Profile preferencesのドキュメント](https://docs.gitlab.com/user/profile/preferences/)にある手順は次のとおりです。

1. 右上のアバターを選び、Preferencesを開く
2. Localizationタブの「Language and region」でLanguageから日本語を選ぶ
3. Save changesを押し、ページを再読み込みする

翻訳が追いついていないメニューは英語のまま残ることがあります。公式ドキュメントは英語の画面名で書かれているので、手順を照らし合わせる間は英語表示のまま進める判断もありです。

### ED25519のSSH鍵を作ってGitLabに登録し接続を確かめる手順

HTTPSでもcloneできますが、毎回の認証を省くならSSH鍵を登録します。[GitLabのSSH鍵のドキュメント](https://docs.gitlab.com/user/ssh/)は、RSAより安全で速いED25519を推奨しています。RSAを使う場合は4096ビット以上が推奨値です。

```
# 鍵の作成（コメントは識別用。メールアドレスを入れることが多い）
ssh-keygen -t ed25519 -C "work-laptop"

# 公開鍵をクリップボードへ（Windows の Git Bash の場合）
cat ~/.ssh/id_ed25519.pub | clip

# GitLab に登録したあと、接続を確認する
ssh -T git@gitlab.com
```

公開鍵は、アバター→Edit profile→左メニューのAccess→SSH keys→Add new keyで貼り付けます。最後のコマンドで「Welcome to GitLab」とユーザー名が返れば登録は完了です。秘密鍵（拡張子なしのid\_ed25519）は貼らないでください。

### 空のプロジェクトを作成してローカルのコードをmainへpushする流れ

右上の「＋」からNew project/repository→Create blank projectを選び、プロジェクト名と公開範囲（Visibility Level）を入れます。[プロジェクト作成のドキュメント](https://docs.gitlab.com/user/project/)にあるとおり、「Initialize repository with a README」にチェックを入れるとデフォルトブランチが作られ、すぐにcloneできる状態になります。

```
# 作成したプロジェクトを手元に複製する（グループ名・プロジェクト名は自分のものに置き換える）
git clone git@gitlab.com:my-group/my-app.git
cd my-app

# 既存のコードを置いて最初のコミットを送る
git add .
git commit -m "Initial import"
git push origin main
```

作成直後のデフォルトブランチ（main）は保護ブランチになっており、Maintainer以上でないと直接pushできません。Developerのメンバーが初回pushで拒否されたら、権限の問題を疑ってください。

## GitLabのIssueでタスク管理する：ラベル・期日・ボードの使い方

### Issueの作成とクイックアクションで担当・期日を1行で入れる方法

Issueは左メニューのPlanから作成します。19.5系の画面ではIssueは「Work items」の一種として並び、種類（Type）をIssueで絞り込んだ画面がIssueの一覧です。タイトルと説明を書き、担当者・ラベル・マイルストーン・期日は右側の欄で設定します。

欄を1つずつ開くより速いのが、説明やコメントに書く[クイックアクション](https://docs.gitlab.com/user/project/quick%5Factions/)です。保存した時点で各欄に反映され、コマンドの行は本文から消えます。

```
/assign me
/label ~bug ~"priority::high"
/milestone %"v1.2"
/due this Friday
/estimate 3h
```

期日を英語の相対表現（in 2 days、this Friday）で書ける点は、日本語化した画面でも同じです。見積もり（estimate）と実績（spend）を入れておくと、後からマイルストーン単位で工数を振り返れます。

### ラベルとイシューボードでカンバン運用を組むときの作業別の列の決め方

[Issue boards](https://docs.gitlab.com/user/project/issue%5Fboard/)はFreeでも使えるカンバン画面で、既定で「Open」と「Closed」の2列があります。間に足す列は[ラベル](https://docs.gitlab.com/user/project/labels/)で定義し、カードを列間でドラッグするとラベルが付け替わります。

列は「To Do」「Doing」「Review」の3つから始めるのが無難です。「設計中」「実装中」「テスト中」と細かく割ると、移動の操作だけが増えてボードの更新が止まります。Review列に入ったIssueは、次の章で作るMRと対になっている状態を目安にします。

期日やマイルストーンでの進捗管理、ガントチャート風の見せ方はスケジュール管理の領域になるため、ここではIssueとボードの基本に絞りました。

## GitLabのマージリクエストでレビューしてmainへ取り込む手順

### IssueからブランチとMRを同時に作り自動でクローズさせる手順

いちばん手数が少ないのは、Issueの画面から作る方法です。[MR作成のドキュメント](https://docs.gitlab.com/user/project/merge%5Frequests/creating%5Fmerge%5Frequests/)どおり、Issueの説明欄の下にある「Create merge request」から「Create merge request and branch」を選ぶと、ブランチとMRが一度にでき、MRの説明欄にはIssueへの参照が入ります。ブランチ名はプロジェクトのブランチ名テンプレートから提案され、ダイアログで変えられます。

手元でブランチを切った場合も、MRの説明に「Closes #12」と書けば紐づきます。[Issueのクローズパターン](https://docs.gitlab.com/user/project/issues/managing%5Fissues/)は、MRがデフォルトブランチへマージされた時点でIssueを自動で閉じる仕組みです。「Related to #5」と書いたIssueは関連づくだけで閉じません。

### git pushのオプションでブラウザを開かずにMRを作るコマンド

ブランチのpushと同時にMRを作るなら、[Gitのpushオプション](https://docs.gitlab.com/topics/git/commit/)が便利です。タイトル・ラベル・ドラフト指定・マージ後のブランチ削除まで1回で渡せます。

```
git switch -c 12-fix-login-error
# 修正してコミットしたあと
git push origin 12-fix-login-error \
  -o merge_request.create \
  -o merge_request.target=main \
  -o merge_request.title="ログインエラーの修正" \
  -o merge_request.label="bug" \
  -o merge_request.draft \
  -o merge_request.remove_source_branch
```

ドラフトのMRはマージできないので、レビュー準備が整ったら画面のMark as readyか、コメントに`/ready`で解除します。毎回同じオプションを打つなら、`git config --global alias.`でエイリアスにしておくと入力が1語で済みます。

### FreeではMR承認が任意になる点と保護ブランチで守れる範囲

[MR承認のドキュメント](https://docs.gitlab.com/user/project/merge%5Frequests/approvals/)によると、FreeではDeveloper以上なら誰でも承認できますが、その承認は任意で、承認なしのマージを止めません。「承認2件が無いとマージ不可」といった必須ルールはPremium以上の機能です。

Freeで守れるのは、[保護ブランチ](https://docs.gitlab.com/user/project/repository/branches/protected/)の「Allowed to merge」と「Allowed to push and merge」です。mainへのpushを「No one」、マージをMaintainerだけに絞れば、少なくとも全員が直接mainを書き換える事態は防げます。レビューの実施そのものは運用ルールで担保するしかありません。

### マージ方式3種とスカッシュ設定をチームでMR作成前に決めておく理由

Settings→Merge requestsで選べる[マージ方式](https://docs.gitlab.com/user/project/merge%5Frequests/methods/)は3つあり、履歴の見え方が変わります。

| 方式                  | mainの履歴      | 向くチーム          |
| ------------------- | ------------ | -------------- |
| Merge commit        | マージコミットが毎回残る | 既定のまま始めたい      |
| Semi-linear history | 直線＋マージコミット   | 履歴を読みやすくしたい    |
| Fast-forward merge  | マージコミットなし    | rebase運用に慣れている |

同じ画面のSquash commits when mergingは「Do not allow」「Allow」「Encourage」「Require」の4段階です。途中で変えると履歴の粒度が混ざるので、最初のMRを作る前に決めます。コミットをまとめる考え方は[git squashの手順とpush済みブランチの扱い](https://www.issoh.co.jp/tech/details/2506/)、ブランチ戦略全体は[Git運用のブランチ戦略とレビュー基準の決め方](https://www.issoh.co.jp/column/details/2379/)を参照してください。

## GitLab CI/CDを動かす：.gitlab-ci.ymlの最小構成とMR時の実行

### buildとtestの2ステージを動かす.gitlab-ci.ymlの最小例

リポジトリのルートに`.gitlab-ci.yml`を置くと、pushのたびにパイプラインが走ります。GitLab.comでは共有のRunnerが用意されているため、[CI/CDのクイックスタート](https://docs.gitlab.com/ci/quick%5Fstart/)にあるとおりRunnerの準備は要りません。

```
stages:
  - build
  - test

default:
  image: node:22

build-job:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test-job:
  stage: test
  script:
    - npm ci
    - npm test
```

同じstageのジョブは並列に、stageどうしは上から順に実行されます。結果は左メニューのBuild→Pipelinesで確認でき、ジョブ名を選ぶと実行ログが見られます。キーワードの全量は[CI/CD YAML構文リファレンス](https://docs.gitlab.com/ci/yaml/)が正本です。

### MRのときだけテストを走らせるrulesと計算分数の見積もり方

Freeの月400分を守るには、ジョブを走らせる条件を絞ります。次の書き方なら、テストはMRの作成・更新時とmainへのマージ時だけ動きます。

```
test-job:
  stage: test
  script:
    - npm ci
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
```

[compute minutesのドキュメント](https://docs.gitlab.com/ci/pipelines/compute%5Fminutes/)では、消費量は「ジョブ時間（分）×cost factor」で、既定のLinux smallは係数1、mediumは2、macOSのM1 mediumは6です。たとえば4分のパイプラインを1日10回、月20営業日動かすと800分になり、Freeの倍を使います。この見積もりが400分を超えるなら、追加購入かPremiumを前提に予算を組んでください。

CI/CDの考え方そのものは[CI/CDの仕組みとパイプライン構成](https://www.issoh.co.jp/column/details/13002/)、他ツールとの料金比較は[CI/CDツール比較の無料枠と料金](https://www.issoh.co.jp/tech/details/1834/)にまとめています。

## GitLabをチームに導入するかの判断：採用する条件と見送る場面

### GitLabを採用すべき条件はIssue・MR・CIを1か所で回したいチーム

採用をすすめるのは、課題管理とレビューとCIを別々のSaaSで契約しており、それぞれの連携設定に手間がかかっているチームです。GitLabならIssue番号がブランチ名・MR・パイプラインまで自動でつながるため、「この修正はどの依頼から来たか」を1画面でたどれます。社内規程でソースコードを自社サーバーに置く必要がある場合も、Self-Managedという選択肢がある点でGitLabが有利です。

GitHubとの機能・料金の詳しい違いは[GitHubとGitLabの違いとCIの対応表](https://www.issoh.co.jp/tech/details/4219/)で比較しています。

### GitLabを見送る場面は承認必須をFreeで済ませたい場合など3つ

次の条件に当てはまるなら、GitLabのFreeで始める計画は見直します。

- レビュー承認を必須にしたいが、Premiumの予算が取れない（Freeの承認は任意）
- 開発メンバーが6人以上いるのに、GitLab.comのFreeで運用しようとしている
- Self-Managedを選んだのに、毎月の更新作業を担当する人がいない

1つ目と2つ目はプランの問題なので、費用を見積もり直せば解決します。3つ目は人の問題で、保守対象外の版を使い続けることになるため、GitLab.comへ切り替えるか運用を外部に任せるかを先に決めてください。パイプラインの設計やRunnerの構築を含めて開発フローを外部に相談したい場合は、一創の[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)で、既存リポジトリの移行から.gitlab-ci.ymlの整備までお手伝いしています。

## よくある質問

GitLabを使い始めるときによく聞かれる質問に、2026年10月時点の公式情報をもとに回答します。

### GitLabは無料でどこまで使えますか？

GitLab.comのFreeプランでは、Issue・MR・CI/CD・イシューボードといった基本機能はすべて使えます。上限はトップレベルグループあたり5ユーザー、CIの計算分数が月400分、ストレージ10GiBです。MR承認の必須化や複数人での承認ルールはPremium以上になるため、レビュー必須の運用をしたい場合は有料プランを検討してください。

### GitLabの画面は日本語化できますか？

日本語への切り替えは可能です。右上のアバターからPreferencesを開き、Localizationタブで言語に日本語を選んで保存し、ページを再読み込みすると切り替わります。設定はユーザーごとなので、チーム全員がそれぞれ変更する必要があります。翻訳されていないメニューが英語のまま残ることもあるため、公式ドキュメントと照らし合わせるときは英語名も覚えておくと迷いません。

### マージリクエストとプルリクエストは何が違いますか？

機能としてはほぼ同じもので、GitLabではマージリクエスト（MR）、GitHubではプルリクエスト（PR）と呼んでいます。ブランチの変更をレビューして取り込むための依頼という役割は共通です。違いが出るのは周辺機能で、GitLabはIssueの画面からブランチとMRを同時に作れる点や、git pushのオプションでMRを作れる点に特徴があります。

### GitLabをタスク管理だけに使うことはできますか？

タスク管理だけの利用も可能です。Issueとラベル、マイルストーン、イシューボードの組み合わせで、コードを置かないプロジェクトでもカンバン形式のタスク管理ができます。ただしFreeでは5ユーザーの上限があり、ガントチャートのような計画機能は上位プランに寄っています。開発以外のメンバーまで含めて大人数で使うなら、専用のタスク管理ツールとの費用比較をしてから決めてください。

### SSH鍵を登録したのにpushできないときは何を確認しますか？

まず`ssh -T git@gitlab.com`でWelcomeのメッセージが返るか確かめます。返らない場合は、登録したのが公開鍵（.pubの中身）か、鍵が途中で切れていないかを見直してください。接続は通るのにpushだけ拒否されるなら、保護ブランチへの直接pushの可能性が高く、mainではなく作業ブランチへpushしてMRを作るのが正しい手順です。

## 関連記事

- [GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較](https://www.issoh.co.jp/tech/details/4219/)：GitLabとGitHubのどちらを選ぶかを機能と料金で比べられます
- [Git運用のベストプラクティス｜ブランチ戦略・コミット規約・レビュー基準の決め方](https://www.issoh.co.jp/column/details/2379/)：MRの運用ルールを決めるときの土台になります
- [CI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】](https://www.issoh.co.jp/tech/details/1834/)：GitLab CI以外の選択肢と無料枠を確認できます
- [GitLabでPR-AgentのAIコードレビューを導入する手順｜CI・Webhook・Qodo Merge Proの選び方](https://www.issoh.co.jp/tech/details/2575/)：MRのレビューをAIで補う構成を扱います
- [GitLab Duo Agent Platformとは？GA後の機能とGitLab Creditsの実費を解説](https://www.issoh.co.jp/tech/details/10660/)：GitLabのAI機能と課金の仕組みを整理しています

---

出典: [GitLabの使い方：プロジェクト作成からIssue・MR・CI/CDまでの手順【2026年10月】](<https://www.issoh.co.jp/tech/details/18874/>)（株式会社一創）