# GitLabとは: Gitとの違い、clone、push、マージリクエスト、CI/CDの使い方 URL: https://skillaria.top/ja/guides/git/what-is-gitlab GitLabは、Gitリポジトリを保存し、チームで開発するためのWebプラットフォームです。コード、マージリクエスト、課題管理、CI/CDを1つにまとめています。クラウドのgitlab.comでも、企業の自社サーバーでも利用でき、コードの送受信は通常のGitコマンド（clone、push、pull）で行います。 ## GitLabとは GitLabは、Gitリポジトリを保存し、そのまわりでチームの作業を進めるためのプラットフォームです。コードの閲覧、マージリクエスト（変更の統合を依頼する仕組み）、課題管理、Wiki、コンテナレジストリ、統合されたCI/CDを提供します。簡単に言えば、「独自のビルドパイプラインを持ち、自社サーバーに導入できるGitHub」です。多くの企業、特に日本やロシアでは、社内ネットワークに構築したGitLabでコードを管理しています。 プロジェクトは2011年に、コードをホスティングするオープンソースのアプリケーションとして始まり、その周りにGitLab Inc.という会社が生まれました。プラットフォームには2種類あります。無料で自社サーバーに導入できるオープンソース版のCommunity Editionと、有料機能を含むEnterprise Editionです。クラウドのgitlab.comでは、Free、Premium、Ultimateというプランがあります。 用語を混同しないように注意しましょう。Gitはバージョン管理システムで、あなたのコンピューター上で動くプログラムです。GitLabは、リモートのリポジトリを保存し、チームのためのインターフェースとツールを追加するサービスです。GitLabがなくてもGitは使えますが、Gitがなければ、GitLabを使うことはできません。 ## GitとGitLabの違い 「gitとgitlabは何が違うのか」という疑問は、求人票や初日の職場で両方の言葉を目にしたときによく生まれます。違いは、ドキュメントとクラウドストレージの関係に似ています。Gitは、ファイルの変更を追跡し、コミットの履歴やブランチをローカルで管理します。GitLabは、その履歴をネットワーク経由で受け取り、ブラウザーに表示します。 | | Git | GitLab | | --- | --- | --- | | 概要 | バージョン管理のプログラム | リポジトリとチーム作業のためのWebプラットフォーム | | 動く場所 | 開発者のコンピューター | gitlab.com、または会社のサーバー | | インターネットの必要性 | 不要（push、pull、fetch、cloneを除く） | 必要（ネットワークサービス） | | 主な機能 | コミット、ブランチ、マージ、履歴 | マージリクエスト、レビュー、課題、CI/CD、アクセス権限 | | 操作方法 | コマンドライン、IDE、GUIクライアント | ブラウザーと通常のGitコマンド | コミット、ブランチ、マージといったコードの操作は、今もGitで行います。GitLabは、`git push` で結果を受け取り、同僚と議論するための場を提供するだけです。 ## GitLabとGitHubの違い GitLabもGitHubも、Gitリポジトリを保存し、コードレビューに対応しています。そのため、基本的なスキルはそのまま持ち運べます。違いは重点と導入モデルにあります。 | 項目 | GitLab | GitHub | | --- | --- | --- | | マージの依頼 | マージリクエスト（MR） | プルリクエスト（PR） | | CI/CD | 組み込みのGitLab CI/CD、ファイルは `.gitlab-ci.yml` | GitHub Actions、ファイルは `.github/workflows/` 内 | | 自社サーバーへの導入 | 無料のCommunity Editionを自社サーバーに | GitHub Enterprise Server（有料） | | プラットフォームのソースコード | 公開（Community Edition） | 非公開 | | プロジェクトの整理 | グループとサブグループ | Organization（組織） | | よく使われる場面 | 企業の開発、社内サーバー | オープンソース、公開プロジェクト、ポートフォリオ | 実際には、両方を使う開発者も多くいます。個人のプロジェクトやポートフォリオはGitHubに、会社の業務コードはGitLabに置く、といった使い分けです。Gitのコマンドは同じで、変わるのはリモートリポジトリのアドレスだけです。 ## gitlab.comか自社サーバー（self-hosted）か クラウドのgitlab.comは、個人のプロジェクトや小規模なチームに向いています。登録すればすぐにリポジトリを作成できます。アップデート、バックアップ、可用性はGitLabが管理します。無料プランの制限（メンバー数、CIの実行時間、ストレージ容量）は時々変わるため、最新の条件はプランのページで確認してください。 Self-hosted GitLabは、企業が自社サーバーにLinux用パッケージ、Docker、Kubernetesのいずれかで導入します。コードが社内ネットワークの外に出ることはなく、LDAPによる社内ログインも設定でき、ビルド用に独自のRunnerを用意できます。その代わり、アップデートとバックアップは管理者が担当します。開発者にとっての違いはほとんどありません。アドレスが `gitlab.com` ではなく、たとえば `gitlab.company.ru` になる程度です。 ## Gitを GitLab用に設定する 最初のコミットの前に、名前とメールアドレスを設定してください。これらは履歴に記録され、GitLabはメールアドレスでコミットをあなたのプロフィールに紐付けます。 ``` git config --global user.name "Ivan Petrov" git config --global user.email "ivan@example.com" ``` Windowsでは、Git for Windowsに含まれるGit Bashを使うと便利です。Git Bashには `ssh-keygen` も含まれているため、この記事のコマンドはそのまま動きます。次に、ログイン方法を選びます。トークンを使うHTTPSか、SSHキーのどちらかです。 ### HTTPSでのログイン: personal access token HTTPSでGitを操作する場合は、アカウントのパスワードを使わないでください。二要素認証を有効にしていれば、パスワードは使えません。代わりに、GitLabのプロフィール設定（Access tokensのセクション）でpersonal access tokenを作成します。コードを扱うには `read_repository` と `write_repository` の権限があれば十分です。有効期限を設定し、トークンはすぐに保存してください。トークンは再度表示されません。 初めて push や clone をするとき、Gitはログイン名とパスワードを尋ねます。ログイン名にはGitLabのユーザー名を、パスワードの代わりにトークンを入力します。Git for Windowsに含まれる資格情報マネージャーが記憶するため、毎回入力する必要はありません。 ### SSHキーでのログイン SSHは、日々の作業には便利です。一度キーを登録すれば、以後は何も入力する必要がありません。 ``` ssh-keygen -t ed25519 -C "ivan@example.com" cat ~/.ssh/id_ed25519.pub ``` 公開鍵（`.pub` のファイル）の内容を、GitLabのプロフィール設定のSSH Keysにある入力欄に貼り付けます。接続を確認するには、次のコマンドを使います。 ``` ssh -T git@gitlab.com Welcome to GitLab, @ivan.petrov! ``` ## GitLabからgit cloneする方法 プロジェクトのページには、SSHとHTTPSの2つのアドレスが表示されるCodeボタンがあります。使いたい方をコピーして `git clone` を実行します。 ``` # HTTPSの場合 git clone https://gitlab.com/my-group/my-project.git # SSHの場合 git clone git@gitlab.com:my-group/my-project.git ``` GitLabのプロジェクトパスには、サブグループが含まれることがあります。たとえば `gitlab.com/company/backend/api.git` のような形です。これは正常なので、アドレスを丸ごとコピーしてください。 ### トークンを使ったGitLabのgit clone パスワードを入力する人がいないスクリプトやサーバーでは、トークンをアドレスに直接埋め込みます。ユーザー名には、あなたのユーザー名か、サービス用の `oauth2` を指定できます。 ``` git clone https://oauth2:YOUR_TOKEN@gitlab.com/my-group/my-project.git ``` 注意してください。このアドレスは `.git/config` に保存され、シェルのコマンド履歴に残る可能性があります。自動化には、最小限の権限と期限を持つdeploy tokenまたはproject access tokenを使いましょう。CIでは、組み込みの `CI_JOB_TOKEN` 変数を使うのが適切です。 ## GitLabへのgit push: コードを送信する プロジェクトがすでにローカルにある場合は、GitLabに空のプロジェクトを作成します（不要なコミットが増えないように、READMEは追加しないでください）。その後、リモートリポジトリを紐付けます。 ``` git remote add origin git@gitlab.com:my-group/my-project.git git branch -M main git push -u origin main ``` `-u` オプションは、ローカルブランチとリモートブランチを紐付けます。以後は `git push` と `git pull` だけで済みます。通常の作業の流れは、ほかのサービスと変わりません。 ``` git switch -c feature/login git add . git commit -m "ログインフォームを追加" git push -u origin feature/login git pull ``` タグは別に送信します。`git push origin v1.2.0` で1つずつ送るか、`git push --tags` ですべて送ります。GitLabではタグがTagsのセクションに表示され、リリースパイプラインを起動することがよくあります。 ### GitLabでgit pushするときのよくあるエラー - **HTTP Basic: Access denied**: ユーザー名が間違っているか、トークンの代わりにパスワードを入力しています。`write_repository` 権限のあるトークンを作成し、資格情報マネージャーの古い記録を削除してください。 - **Permission denied (publickey)**: GitLabがSSHキーを認識していません。公開鍵がプロフィールに登録されているか確認し、`ssh -T git@gitlab.com` を実行してください。 - **You are not allowed to push code to protected branches**: ブランチ（通常は `main`）が保護されています。自分のブランチに送信し、マージリクエストを作成してください。 - **rejected ... (fetch first)**: サーバーにあなたの手元にないコミットがあります。`git pull --rebase` を実行してから、もう一度pushしてください。 - **remote: Project not found**: アドレスのタイプミス、またはプロジェクトへのアクセス権がありません。オーナーに権限を確認してください。 ## GitLabのマージリクエスト マージリクエストは、GitHubのプルリクエストに相当します。あなたのブランチを、メインのブランチに取り込んでほしいという依頼です。MRでは、同僚がコードの行にコメントし、CIチェックが実行され、マージの判断が行われます。新しいブランチをpushすると、GitLabはターミナルにMR作成用のリンクを表示し、Webインターフェースでも作成を提案します。 push optionsを使えば、コマンドラインからMRを作成することもできます。 ``` git push -o merge_request.create -o merge_request.target=main origin feature/login ``` 典型的な流れは、タスクごとのブランチ、コミット、push、MR、レビューと緑のパイプライン、マージです。マージのとき、GitLabはコミットを1つにまとめ（squash）、元のブランチを削除することができます。MRにコンフリクトがある場合は、ローカルでブランチを更新するのが簡単です。`git pull --rebase origin main` か `git merge main` を実行し、コンフリクトを解決して、もう一度pushしてください。 未完成の作業は、Draftとして示してください。下書きのMRは誤ってマージされることがありませんが、同僚は変更を見て議論できます。 ## GitLab CI/CD: .gitlab-ci.yml GitLabの大きな特徴は、CI/CDが組み込まれていることです。リポジトリのルートに `.gitlab-ci.yml` ファイルを置くだけで、pushのたびにGitLabがパイプラインを実行します。パイプラインはステージ（stages）とジョブ（jobs）から構成されます。ジョブはRunnerが実行します。gitlab.comには共有のRunnerがあり、自社サーバーでは別途Runnerを導入します。 ``` stages: - test - deploy test: stage: test image: python:3.12 script: - pip install -r requirements.txt - pytest deploy: stage: deploy script: - ./deploy.sh rules: - if: $CI_COMMIT_TAG ``` この例では、テストはpushのたびに実行されますが、`deploy` ジョブはタグが送信されたときだけ動きます。`git tag v1.0.0` と `git push origin v1.0.0` を実行すると、デプロイが始まります。パイプラインの結果はマージリクエストに直接表示され、チェックが通るまでマージを禁止することもできます。 ## GitLabのリポジトリを削除する方法 Gitのコマンドでは、サーバー上のプロジェクトを削除できません。`git push` が変えるのはブランチとタグだけです。プロジェクトの削除はWebインターフェースで行います。プロジェクトの設定から General を開き、Advanced ブロックにある削除ボタンを、プロジェクト名の確認入力とともに押します。Owner（オーナー）の権限が必要です。ローカルのコピーは残ります。それは `.git` を含む普通のフォルダにすぎません。 サーバーには何も残さずに、ローカルリポジトリをGitLabから切り離したいだけなら、`git remote remove origin` で十分です。 ## GitLabを選ぶべき場合 - コードを外部のクラウドに出せず、自社サーバーが必要な場合。 - 外部サービスを使わずに、CI/CDが最初から使える必要がある場合。 - グループの階層がある大きな組織で、ネストしたグループや柔軟な権限が必要な場合。 - すでにGitLabを使っている会社に入社する場合。この場合は選択の余地はありませんが、Gitのスキルはそのまま活かせます。 ポートフォリオやオープンソースには、一般的にGitHubが選ばれます。コミュニティが大きく、プロジェクトの見つけやすさも高いからです。両方のサービスに同じプロジェクトを置くことも可能です。リポジトリには複数のremoteを設定できます。 ## まとめ GitLabは、マージリクエストによるレビュー、課題、組み込みのCI/CDを備えたGitリポジトリのプラットフォームです。クラウドでも自社サーバーでも利用できます。作業は、なじみのあるコマンドで行えます。トークンかSSHキーでログインを設定し、clone、commit、push、マージリクエストの順に進めてください。リモートリポジトリとチームでのワークフローは、Gitのコースで実践的に扱っています。 ## FAQ **GitLabは無料ですか？** 自社サーバーに導入するCommunity Editionは無料です。gitlab.comには無料のFreeプランがありますが、機能に制限があります。高度な機能はPremiumとUltimateの有料プランで提供されています。 **GitHubからGitLabにプロジェクトを移行できますか？** はい。GitLabにはGitHubからのプロジェクトのインポート機能があります。履歴を手動で移すこともできます。古いアドレスに対して git clone --mirror を実行し、新しいアドレスに git push --mirror します。 **GitLab専用のコマンドを覚える必要がありますか？** いいえ。コードの操作には通常のGitコマンドを使います。GitLabはWebインターフェースを追加し、自動化のためにはコマンドラインツールの glab やAPIを提供しています。 **GitLab FlowとGit Flowはどう違いますか？** GitLab Flowはよりシンプルです。作業はfeatureブランチで行い、mainへのマージリクエストで統合します。環境やリリースに応じて、必要なら専用のブランチを追加します。Git Flowのようなdevelopブランチやhotfixブランチは必要ありません。 --- Source: Skillaria.Top (https://skillaria.top)