GitとGitHubの違いは分かった。でもGitLabは何なのか。名前が似ていて、できることも似ていて、取引先によって使っているものが違います。サンプル料理教室の代表も、制作会社に聞かれるまで同じものの別名だと思っていました。読み終わると、2つの違いを料金・機能・自社サーバーの3つで説明でき、自社がどちらを選ぶか決められます。
この記事の内容
先に答えると
GitHubとGitLabは、どちらもGitの履歴を預かる置き場所のサービスで、別の会社が運営する別の製品です。Gitの履歴の中身は同じなので、あとから引っ越せます。迷っている小さな会社は、GitHubのFreeから始めて足ります。
- 運営が違う。GitHubはMicrosoft傘下、GitLabはGitLab Inc.
- 無料の人数が違う。GitHub Freeは非公開の共同作業者に上限なし、GitLab.com Freeは非公開のトップレベルで5ユーザーまで
- 自動処理の無料枠が違う。GitHub Freeは月2,000分、GitLab.com Freeは月400コンピュート分（2026年11月時点）
- 自社サーバーの入口が違う。GitHubはEnterpriseのプランから、GitLabはFreeの段から
- 移すと履歴は持っていけるが、自動処理の設定は書き換えが要る
GitLabとは何か
GitLabは、Gitの履歴を置いて、変更の確認や自動処理まで同じ画面でやるサービスです。GitHubと同じ種類のものです。GitHub.comに当たるのがGitLab.comで、これに加えて自社のサーバーに入れて動かす形（GitLab Self-Managed）があります。
ここで押さえておくのは、Git本体はどちらの会社のものでもないことです。手元で打つ git add も git commit も git push も、GitHubとGitLabで同じです。違うのは送り先と、送り先の画面と、料金です。
比較の表
値は公式のページで確かめたもので、2026年11月時点です。GitLabの値は、特に断りがなければGitLab.comの料金表のものです。
| 比べるところ | GitHub | GitLab |
|---|---|---|
| 運営 | GitHub（2018年にMicrosoftが買収） | GitLab Inc. |
| 料金（1ユーザー月） | Free $0、Team $4、Enterprise $21 | Free $0、Premium $29（年額請求）、Ultimate 個別見積 |
| 無料の人数 | 非公開の共同作業者は上限なし | 非公開のトップレベルnamespace（会社やグループの一番上の単位）は5ユーザーまで。超えると読み取り専用 |
| 自動処理の無料枠 | Free 月2,000分。公開リポジトリは標準のランナーなら無料 | Free 月400コンピュート分 |
| 有料の自動処理枠 | Team 3,000分、Enterprise 50,000分 | Premium 10,000分、Ultimate 50,000分 |
| ストレージ | リポジトリは1GB未満が理想、5GB未満を強く推奨。Actionsの成果物とPackagesはFreeで500MB | プロジェクトごとにFree 10GiB、Premium・Ultimate 500GiB |
| 自社サーバー | Enterpriseのプランで GitHub Enterprise Server | Self-Managed に Free、Premium、Ultimate の段 |
| 変更の確認の呼び名 | プルリクエスト（Pull Request、PR） | マージリクエスト（Merge Request、MR） |
| 自動処理の設定ファイル | .github/workflows の中のファイル | .gitlab-ci.yml |
| AI機能 | GitHub Copilot。個人はFree $0、Pro $10、Pro+ $39など | GitLab Duo。AI機能は GitLab Credits で使う形で、Freeは追加購入、Premiumは月$12、Ultimateは月$24のクレジットが1ユーザーあたり含まれる（GitLab.comのみ、期間限定の記載） |
| 秘密情報の検出 | 公開は無料で自動。非公開は Secret Protection を有効にした Team・Enterprise Cloud | Secret Detection は全プランで基本機能（Free・PremiumはLimited）。Secret push protection は Ultimate のみ |
| 非公開の枝の保護 | Freeは対象外。個人はPro、OrganizationはTeam以上 | Freeから。既定の枝は最初から保護される。必須の承認はPremium以上 |
| 非公開のWiki・Pages | Freeは対象外。個人はPro、OrganizationはTeam以上 | Freeから |
| ソースの公開状況 | 自社サーバー版は完成品の仮想マシンとして配布 | gitlab-foss がMITライセンスの読み取り専用ミラー（独自コードを除いたもの） |
表だけだと読み違えやすいところを補います。
料金は同じ段どうしの値段ではない
TeamとPremiumは名前の位置が似ていますが、含む機能も自動処理の枠も違います。金額だけ並べて「GitHubが安い」とは言えません。ただ、小さな会社にとって入口の金額が効くのは確かです。6人で計算すると、Teamは月$24、GitHub Enterpriseは月$126、GitLab Premiumは月$174です。Premiumは年額請求なので、1年分で$2,088になります。
無料の人数は、一番差が出るところ
GitHub Freeは料金ページの「Collaborators for private repositories」が「Unlimited」です。GitLab.com Freeの5ユーザーの上限は、非公開のトップレベルnamespaceにかかります。公開グループ、個人のnamespace、有料プラン、Self-Managedは対象外です。もう1つ、2026年1月27日より後に作ったFreeアカウントは、トップレベルグループが3つまでです。
サンプル料理教室なら、今はGitを触るのが代表と外注エンジニアBの2人なのでGitLabの5人にも収まります。教室の6人全員とBを入れて7人になると読み取り専用になり、新しい変更を書き込めません。
自動処理の分数は、同じ1分ではない
GitHubは標準のLinuxで1分$0.006という金額が基準で、月2,000分は$12分に当たります。Windowsは1分$0.010、macOSは1分$0.062なので、同じ枠でも減り方が違います。GitLabはコンピュート分に機械ごとの倍率をかけます。小さいLinuxのランナー（処理を動かす機械）は1倍、macOSのM1のmediumは6倍です。どちらも、小さなLinuxのランナーで動かすなら、書いてある分数に近い感覚で使えます。
Freeの非公開では、GitLabのほうが使える機能もある
非公開の枝の保護とWiki、Pagesは、GitLabはFreeからで、GitHubのFreeでは非公開だと使えません。GitHub Freeは「人数と自動処理の枠が広く、非公開の機能は絞ってある」、GitLab.com Freeは「人数と枠は小さく、非公開でも機能が多い」と言えます。
一方、GitLabのFreeで枝を保護しても、マージリクエストの承認は任意です。承認がないと合流できないようにするのはPremium以上です。
呼び名の対応表
別の製品なので、同じものに別の名前がついています。話がかみ合わないときは、たいていここです。
| GitHub | GitLab | 何のことか |
|---|---|---|
| Pull Request | Merge Request | 変更を合流させる前の確認 |
| Organization | Group | 会社やチームの単位 |
| Repository | Project | コードの置き場所。GitLabのProjectはリポジトリを中に持つ |
| GitHub Actions | GitLab CI/CD | 決めたきっかけで処理を動かす機能 |
| Runner | Runner | 処理を動かす機械。名前は同じ |
.github/workflows | .gitlab-ci.yml | 自動処理の設定 |
on | rules | いつ動かすか |
runs-on | tags | どの機械で動かすか |
run | script | 動かすコマンド |
uses | include | 別の設定を読み込む。1対1では置き換わらない |
CI/CDは、変更のたびに確認や公開を自動で回す仕組みのことです。外注エンジニアBが「MR出しました」と言ったら、プルリクエストのことだと読み替えて構いません。
GitLabで差分を見るところ
「gitlab diff」で探している人が多いので、ここに書いておきます。差分（変更前後の比較）は、マージリクエストを開いてタイトルの下の「Changes」で見ます。表示は「Inline」と「Side-by-side」を切り替えられます。Inlineは古い行の下に新しい行が並び、Side-by-sideは左右に並びます。小さな修正はInline、たくさんの行を直したときはSide-by-sideのほうが読みやすいです。
手元で git diff を打つなら、GitHubでもGitLabでも結果は同じです。Gitの機能だからです。
自社サーバーに置く話を正確に
「GitLabは自社サーバーに置ける、GitHubは置けない」と言われることがありますが、これは正確ではありません。GitHubも置けます。違いは始められる入口の価格です。
| 比べるところ | GitHub Enterprise Server | GitLab Self-Managed |
|---|---|---|
| 必要なプラン | Enterprise（$21） | Free（$0）、Premium（$29、年額請求）、Ultimate（個別見積） |
| 置ける場所 | 自社のデータセンター、AWS、GCP、Azure | 自社で用意する環境 |
| 更新・バックアップ | 自社の管理者の仕事 | 自社の仕事 |
GitHub Enterprise Serverの公式の説明には、インスタンスを最新に保つ責任は管理者にある、と書かれています。GitLabの料金ページのFAQにも、Self-Managedは自社の環境に入れて設定し、維持するものだと書かれています。Freeの段には “Bring your own storage and runners” とあり、保存先と処理を動かす機械も自社で用意します。
ここで見落としやすいのは、料金が$0でも無料ではないことです。Self-Managedにすると、次の仕事が会社に残ります。GitHub Enterprise Serverでも、更新とバックアップは同じです。
- サーバーの費用を払い、容量を見る
- GitLab本体の更新を、脆弱性の修正が出るたびに当てる
- バックアップを取り、戻せることを確かめる
- 止まったら自分たちで直す
- 自動処理を動かす機械（ランナー）を用意する
代表と外注エンジニアBの2人では、この仕事を回す人がいません。外注するとその費用がかかります。実際に運用していると、更新が後回しになった自社サーバーはクラウドより危なくなりやすいです。「社外に置けない」という明確な理由がないなら、自社サーバーは選ばないほうがいいです。
CEとも呼ばれるCommunity Editionの入口はGitLabのサイトにあります。ソースについては gitlab-foss という、独自のコードを除いた読み取り専用のミラーが公開されています。小さな会社がソースの公開状況で製品を選ぶ場面はあまりありません。社内の規定で求められているときに確かめれば足ります。
どう選ぶか
機能の多さではなく、自社の場面で決めます。
| 場面 | 選ぶもの | 理由 |
|---|---|---|
| 小さな会社で、AIと一緒に初めてコードを触る | GitHub | Freeの人数と枠で足りる。Copilotも同じ会社の製品 |
| 社外にコードを出せない規定があり、運用する人がいる | GitLab Self-Managed | Freeの段から試せる |
| 社外に出せない規定があり、すでにGitHubのEnterpriseを使う | GitHub Enterprise Server | 使い慣れた画面のまま自社に置ける |
| Jiraを使っている | Bitbucketも候補 | 同じAtlassianの製品。Free（5ユーザー・50分）、Standard $3.65、Premium $8 |
| 取引先がどちらかを使っている | 取引先に合わせる | 招待で入るので、自社で選ぶ話ではない |
| 5人以内で、非公開でも枝の保護を無料で使いたい | GitLab.com Free | 枝の保護がFreeから |
| 人数は少ないが自動処理をよく動かす | GitHub | 無料枠が多い。公開リポジトリならさらに有利 |
最後に一番強いのが、取引先に合わせる、です。制作会社に「GitHubで招待します」と言われているのに別のものを選んでも、得るものがありません。
Googleドライブでいいのでは、という場面も残ります。コードではなく資料を共有するだけなら、どちらも要りません。
サンプル料理教室の結論
GitHub Freeにしました。理由は4つです。
- 触るのは代表と外注エンジニアBの2人で、Freeの範囲に収まります
- 受付Aや別の外注が増えても、共同作業者の人数で止まりません
- 予約メールのスクリプトを自動で動かすとしても、月2,000分あれば十分です
- 制作会社がGitHubで招待してくれるので、合わせるのが自然です
捨てたものもあります。GitHub Freeでは、非公開の website の枝を保護できません。GitLabならFreeで保護できます。ここはルールで補います。代表は main へ直接送らず、fix-menu-price のような枝を切ってプルリクエストを出し、外注エンジニアBが確認してから合流します。これで困るようになったらGitHub Teamに上げます。2人分で月$8です。
乗り換えを考えるのは、次のようなときです。
- 取引先や親会社から、社外にコードを置かない規定を求められたとき
- 主な外注先がGitLabで動いていて、合わせたほうが速いとき
- 人数は5人以内のままで、自動処理より非公開の機能を無料で使いたいとき
それ以外の理由で乗り換える必要はあまりありません。移す手間のほうが大きくなります。
移すときの手間
履歴は簡単に移ります。Gitの履歴はどこに置いても同じだからです。手元の2つのフォルダをGitHubとGitLabに見立てて、実際に試しました。2つ目のコマンドは、できた mirror.git の中で打ちます。
$ git clone --mirror github-side/website.git mirror.git
Cloning into bare repository 'mirror.git'...
done.
$ git push --mirror ../gitlab-side/website.git
To ../gitlab-side/website.git
* [new branch] add-summer-class -> add-summer-class
* [new branch] main -> main送り先は空の新しいリポジトリにします。--mirror は送り先を手元に丸ごと合わせるので、既存のリポジトリに送ると、手元に無いブランチは消えます。
送った先の履歴を見ると、コミットの番号まで同じです。
$ git log --oneline --all
5030136 夏の教室を追加
0e67fed 料金表を修正
4245380 料金表を追加手元のフォルダは、送り先の設定を変えるだけで使い続けられます。
$ git remote set-url origin git@gitlab.com:sample-cooking/website.git
$ git remote -v
origin git@gitlab.com:sample-cooking/website.git (fetch)
origin git@gitlab.com:sample-cooking/website.git (push)ただ、これで移るのはGitの履歴だけです。Issue（やることのメモ）やプルリクエストはGitの外にあります。GitHubからGitLabへ移すなら、公式のインポーターを使います。
| 区分 | 内容 |
|---|---|
| 持っていける | リポジトリの全ブランチ、Issue、Pull request、コメントとレビュー、Label、Milestone、Wiki、ブランチ保護ルール、Git LFS、Collaborators（取り込む人がGitHub側でWriteかMaintainの権限を持つとき）、Release notes |
| 持っていけない | Outside collaborators（組織の外の共同作業者）、「Require status checks to pass before merging」のルール、Organization そのもの |
| 止まることがある | カスタムロールの共同作業者。移行が一部で止まることがある |
| 形が変わる | ユーザーの対応づけ条件を満たさないと、レビュアーと承認はコメントとして残る |
| 書き換えが要る | GitHub Actionsの設定。そのままでは動かない |
GitLab.comではGitHubのインポート機能は既定で有効です。Self-Managedでは管理者の設定を確かめます。移す先のグループにはMaintainerかOwnerの権限が要ります。
自動処理が一番手間です。.github/workflows の中身を読んで、.gitlab-ci.yml に書き直します。uses で読み込んでいた部品は、include に1対1で置き換わりません。動かして確かめるところまでが引っ越しです。詳しい手順は「GitLabの使い方：無料の範囲、CI/CD、GitHubからの移行」に書きました。
できないことと、その代わり
| どちらにも期待できないこと | その代わり |
|---|---|
| 写真や動画の置き場所 | Googleドライブなど |
| 文書の同時編集 | Googleドキュメントなど |
| 自社サーバーに置けば運用が要らない、という状態 | 運用する人を決める。いなければクラウドを使う |
| 片方の機能をもう片方へそのまま持っていく | 移す前に使っている機能を書き出す |
| 外に漏らしたパスワードの取り消し | 検出機能に頼らず、まず無効にして作り直す |
秘密情報の検出も万能ではありません。入れないことが先で、検出はその次です。入れてはいけないファイルは .gitignore で外します。
よく詰まるところ
GitLab.comで急に書き込めなくなった
非公開のトップレベルnamespaceが5ユーザーを超えて、読み取り専用になっています。リポジトリ、Git LFS、パッケージ、レジストリに新しく書けません。メンバーを5人以下に減らすか、有料プランにします。
GitLabで main に直接pushできない
既定の枝は最初から保護されています。Developerの権限だと、許可されていなければ送れません。枝を切ってマージリクエストを出すか、MaintainerかOwnerの人に保護の設定を確かめてもらいます。
引っ越したのに自動処理が動かない
GitLabは .github/workflows を見ません。.gitlab-ci.yml に書き直します。ランナーの指定は runs-on ではなく tags です。
手元の変更が古い置き場所に送られている
送り先の設定が残っています。git remote -v で確かめて、git remote set-url origin で新しいアドレスに変えます。
インポートが途中で止まった
GitHub側のカスタムロールの共同作業者が原因の可能性があります。そのリポジトリの共同作業者の設定を見直してから、もう一度試します。
レビューの承認が、ただのコメントになった
ユーザーの対応づけ条件を満たしていません。公式の条件を確かめて、GitLab側のユーザーを整えてから取り込み直します。古いプルリクエストの記録で足りるなら、そのままでも困りません。
話がかみ合わない
相手はMRと言い、こちらはPRと言っているだけかもしれません。呼び名の対応表で読み替えます。
次に読む
GitLabを実際に触るなら「GitLabの使い方：無料の範囲、CI/CD、GitHubからの移行」、GitHubの料金をプランごとに知りたいなら「GitHubの料金：Free・Team・Enterpriseと無料でできる範囲」です。公開と非公開の考え方は「GitHubとは：できることと、公開・非公開の考え方」に、変更の確認の流れは「プルリクエストとは：作り方・レビュー・マージの流れ」に書きました。
Atlassianのサービスも並べて比べるなら「Bitbucketとは：GitHub・GitLabとの違いと料金、向いている会社」です。