GitLab入門 — GitHubとの違いと実務で使う機能

会社ではGitLab、個人ではGitHub、という組み合わせはよくある。どちらも「Gitリポジトリのホスティング+開発支援機能」のサービスで、Gitの操作自体は全く同じ。違うのはその上に載っている機能と用語。GitHub経験者がGitLabで迷わないための整理をする。

GitLabとは

Gitリポジトリを中心に、課題管理・コードレビュー・CI/CD・デプロイまでを1つに統合した「DevOpsプラットフォーム」。提供形態が2つある:

• GitLab.com — SaaS版。GitHubと同じ感覚で使うクラウドサービス
• Self-Managed（自社ホスティング） — 自社サーバーやクラウドに自分たちでGitLabを立てる形態。会社で使われているGitLabはたいていこれ。コードを外部に置けない事情がある企業で選ばれやすく、無料のCommunity Edition（CE）でも一通り動く

会社のGitLabのURLが gitlab.example.co.jp のような社内ドメインなら、Self-Managed版。バージョンアップも自社管理なので、GitLab.comより機能が古いことがある。

用語の対応表（GitHub → GitLab）

概念はほぼ1対1で対応する。名前が違うだけのものが多い。

Merge Requestの実務フロー

GitHubのPRと同じ流れ。用語だけ読み替える。

git switch -c feature/add-login   # ブランチを切る
# 変更してコミット
git push -u origin feature/add-login

push後にターミナルへMR作成用のURLが表示される（GitLabの便利機能）ので、それを開いてMRを作るのが最短。あとは:

• レビュワーをAssign → レビュー → スレッド（GitHubのconversationに相当）を解決
• Approve: 承認者数のルールをプロジェクト側で強制できる（設定次第で承認がないとマージボタンが押せない）
• マージ方式は「マージコミット / squash / fast-forward」からプロジェクト設定で選ばれていることが多い。squash運用のプロジェクトではコミットを細かく積んでも1つに潰される
• main や develop はprotected branchになっているのが普通で、直接pushは弾かれる。「pushできない」と思ったらまずこれ

GitLab CI/CDの基本

GitHub Actionsに相当する機能が最初から組み込まれている。リポジトリ直下の .gitlab-ci.yml に書く:

stages:
  - test
  - build

lint:
  stage: test
  image: node:22
  script:
    - npm ci
    - npm run lint

build:
  stage: build
  image: node:22
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

GitHub Actionsとの考え方の違い:

• ワークフローファイルはリポジトリに1つ（.gitlab-ci.yml）が基本。GitHubのように .github/workflows/ に複数置く方式ではない（includeで分割はできる）
• stageという概念でジョブを段階分けし、同じstageのジョブは並列、次のstageは前が全部成功したら進む
• 実行環境のRunnerは、GitLab.comなら共用Runnerがあるが、Self-Managedでは会社が用意したRunnerで動く。「CIが詰まってる」ときはRunnerの空き待ちが原因のことが多い
• MRを作るとパイプラインが走り、結果がMR画面に出る。パイプライン成功をマージ条件にする設定が定番

GitHubとの使い分け・思想の違い

• GitHub: OSSと個人開発の中心地。世界中の開発者のプロフィール・ポートフォリオを兼ねる。Actions・Copilot等の周辺サービスの進化が速い
• GitLab: 「計画 → 開発 → CI/CD → 監視」までを1製品で完結させる思想（The DevOps Platform）。Self-Managedできることが最大の強みで、社内システムとして採用されやすい
• 機能面では、今はどちらも「Git + レビュー + CI + 課題管理」が揃っていて、日常の開発体験に大差はない。差が出るのは管理・運用側（ホスティング形態、権限階層、監査）

個人開発の公開リポジトリはGitHub、会社の内部開発はGitLab、という住み分けが実際のところ一番多い。

会社のGitLabで最初に確認すること

1. SSH鍵の登録（プロフィール → SSH Keys）。社内GitLabはHTTPSよりSSHクローン運用のことが多い
2. 自分のロール（Guest / Reporter / Developer / Maintainer / Owner）。Developerだとprotected branchへのpushやMRマージができない設定が普通
3. プロジェクトのMRルール（承認者数、squashの有無、パイプライン必須か）
4. .gitlab-ci.yml を眺めて、push時に何が走るのか把握しておく

まとめ

• GitLab = Gitホスティング + DevOps統合。会社にあるのはたいていSelf-Managed版
• PRはMRと呼ぶ。Organization → Group、Actions → CI/CDなど用語の読み替えだけで、Git操作は完全に同じ
• CIは .gitlab-ci.yml 1ファイル + stage + Runner。MR画面と統合されている
• 迷ったら「GitHubでいう◯◯はGitLabの△△」と対応表で考えれば大体合っている