図解でわかるGitLabの使い方：初心者向け解説

By /

図解でわかるGitLabの使い方：初心者向け解説

はじめに：GitLabとは何か？なぜ使うのか？

ソフトウェア開発の世界では、チームでコードを共有し、変更履歴を管理し、協力して作業を進めることが不可欠です。そのために利用されるのが「バージョン管理システム」です。中でも「Git」は、分散型バージョン管理システムとして世界中の開発者に広く使われています。

しかし、Gitは基本的にローカルコンピュータ上で動作するコマンドラインツールです。チームで共同作業を行うためには、コードを共有するための中央集権的な場所や、より高度なコラボレーション機能が必要になります。そこで登場するのが、「Gitホスティングサービス」と呼ばれるプラットフォームです。GitHub、Bitbucket、そして本記事の主役である「GitLab」などがその代表例です。

Gitとは？

Gitは、Linus Torvalds氏がLinuxカーネル開発のために開発した分散型バージョン管理システムです。

  • 分散型: 各開発者のローカルコンピュータ上にコードの完全な履歴が保存されます。中央サーバーに障害が発生しても、ローカルの履歴から復旧可能です。
  • バージョン管理: ファイルの変更履歴を記録し、いつでも過去の状態に戻したり、変更内容を確認したりできます。
  • ブランチ: 開発者はメインのコードの流れから枝分かれさせて独立した作業を進めることができます。これにより、複数の機能を並行して開発したり、実験的な試みを行ったりしやすくなります。
  • マージ: 枝分かれしたブランチでの変更を、元のブランチに取り込むことができます。

Git自体は非常に強力ですが、コマンドラインでの操作が中心となるため、初心者には少し敷居が高いかもしれません。また、チームでのコード共有やレビュー、課題管理、CI/CD（継続的インテグレーション/継続的デプロイ）といった、現代のソフトウェア開発に必要な多くの機能はGit単体では提供されません。

GitLabとは？

GitLabは、Gitリポジトリのホスティング機能を中心に、ソフトウェア開発ライフサイクル全体をカバーする様々な機能を提供するWebベースのDevOpsプラットフォームです。単なるコード置き場ではなく、企画、開発、テスト、デプロイ、運用、監視といった一連のプロセスをGitLab上で行うことができます。

GitLabの主な特徴とメリット：

  1. 統合されたDevOpsプラットフォーム: Gitリポジトリ管理だけでなく、課題管理 (Issues)、コードレビュー (Merge Request)、Wiki、CI/CDパイプライン、コンテナレジストリ、セキュリティスキャンなど、開発に必要な機能がオールインワンで提供されています。これにより、複数のツールを連携させる手間が省け、開発プロセスをスムーズに進めることができます。
  2. 強力なCI/CD機能: GitLab CI/CDは、.gitlab-ci.ymlという設定ファイルをリポジトリに置くだけで、コードの変更をトリガーに自動的にテストやビルド、デプロイを実行できます。これはGitLabの最大の強みの一つです。
  3. オープンソースと商用版: GitLabにはオープンソースのCommunity Edition (CE) と、より多くの機能やサポートが含まれる商用版のEnterprise Edition (EE) があります。SaaSとしてのGitLab.comも提供されており、手軽に利用開始できます。
  4. 高いカスタマイズ性: プロジェクト設定、CI/CDパイプラインなどを柔軟に設定できます。

本記事の対象読者と目的

本記事は、Gitやバージョン管理の経験が浅い方を対象としています。

  • GitLabを使って初めてコードを管理したい方
  • チームでGitLabを使って開発を始めたい方
  • GitLabの基本的な機能（リポジトリ操作、マージリクエスト、課題管理、CI/CDの入門）を理解したい方

本記事を読むことで、Gitの基本を理解し、GitLabを使ったプロジェクトの開始からチームでの共同作業、簡単なCI/CDの仕組みまで、一通りの開発ワークフローを体験できるようになることを目指します。

さあ、GitLabの世界に飛び込んでみましょう！

Gitの基本を理解する：GitLabを使うための土台

GitLabはGitをベースにしたプラットフォームです。GitLabを効果的に使うためには、最低限のGitの概念と操作を理解しておく必要があります。ここでは、Gitの基本的な概念を図解のイメージを交えながら解説します。

リポジトリ (Repository)

Gitにおけるリポジトリとは、プロジェクトのすべてのファイルやディレクトリ、そしてそれらの変更履歴をすべて格納している場所です。「バージョン管理の対象となるフォルダ一式」だと考えてください。

  • ローカルリポジトリ: 自分のコンピュータ上に存在するリポジトリです。ここでコードの変更やコミットなどの作業を行います。
  • リモートリポジトリ: GitLabのようなサーバー上に存在するリポジトリです。チームメンバーとコードを共有するために使われます。

図解：リポジトリの概念

+-----------------+ +-----------------+
| ローカルリポジトリ | | リモートリポジトリ |
| (あなたのPC上) | <--> | (GitLabサーバー上) |
| | | |
| .gitフォルダ (履歴) | | コードファイル |
| コードファイル | | .gitフォルダ (履歴) |
+-----------------+ +-----------------+

この図は、ローカルリポジトリとリモートリポジトリが互いにコードや履歴をやり取りする関係であることを示しています。ローカルで作業した内容をリモートに送信したり、リモートの最新のコードをローカルに持ってきたりします。

コミット (Commit)

コミットとは、ファイルに対する一連の変更を確定し、その変更履歴をリポジトリに記録する操作です。「変更のスナップショットを保存する」と考えてください。各コミットには、誰が、いつ、どのような変更を行ったのかという情報（コミットメッセージ）が含まれます。コミットメッセージは、後で履歴を振り返る際に非常に重要になります。

図解：コミットの積み重ね

[最初の状態] -- (Commit A) --> [変更 A の状態] -- (Commit B) --> [変更 B の状態] -- (Commit C) --> [変更 C の状態] ...

この図は、プロジェクトの履歴がコミットという単位で時間の流れに沿って積み重ねられていく様子を示しています。各コミットは一つ前のコミットを親として参照し、変更の連なりを形成します。

ブランチ (Branch)

ブランチは、開発の履歴から枝分かれした、独立した作業ラインです。新しい機能の開発やバグ修正を行う際に、メインの開発ライン（一般的には main や master と呼ばれるブランチ）からブランチを切って作業を進めるのが一般的です。これにより、メインの開発ラインに影響を与えることなく、安全に開発を進めることができます。作業が完了したら、そのブランチでの変更をメインのブランチに合流させます（マージ）。

図解：ブランチの概念

main (メインの作業線)
|
| -- (Commit A) -- (Commit B) -- (Commit C) ...
|
+-- (ブランチ作成) --- feature-X (新機能開発線)
|
| -- (Commit D) -- (Commit E) ...

この図は、main ブランチから feature-X という新しいブランチが作成され、それぞれ独立したコミットが積み重ねられている状態を示しています。feature-X ブランチでの作業は、main ブランチのコミットには影響しません。

マージ (Merge) / マージリクエスト (Merge Request – GitLab)

マージとは、異なるブランチで行われた変更を一つのブランチに合流させる操作です。例えば、新機能開発が完了した feature-X ブランチを main ブランチにマージすることで、main ブランチに新機能のコードが取り込まれます。

GitLabでは、このマージを行うための機能として「マージリクエスト (Merge Request – MR)」を提供しています。単にコードを合流させるだけでなく、コードレビューを依頼したり、自動テストを実行したり、議論を行ったりするためのコラボレーション機能が組み込まれています。チーム開発においては、直接マージするのではなく、マージリクエストを作成してレビューを経てからマージするのが一般的なワークフローです。

図解：マージリクエストを含むマージの流れ

+-----------------+ +-----------------+
| 開発者 (ローカル) | | GitLab (リモート) |
+-----------------+ +-----------------+
| ^
| |
| 1. 新機能ブランチ作成 |
| (例: feature/login) |
| |
| 2. コード変更、コミット |
| |
| 3. ブランチをリモートへプッシュ |
| |
|--------------------->|
| | 4. GitLabでMerge Request作成 (feature/login -> main)
| | + コードレビュー依頼
| | + CI/CD自動実行
| |
| | 5. レビュー、議論、承認
| |
|<---------------------| (レビュー結果、コメントなど)
| |
| 6. 必要に応じてコード修正、プッシュ |
|--------------------->|
| | 7. MR承認後、mainブランチへマージ実行
| |
| v
+-----------------+ +-----------------+
| mainブランチ更新 | | mainブランチ更新 |
+-----------------+ +-----------------+

この図は、開発者がローカルでブランチを作成し、コードを書いてコミット・プッシュし、GitLab上でマージリクエストを作成して、チームメンバーによるレビューや自動テストを経て、最終的にメインのブランチにマージされるまでの一連の流れを示しています。

リモートリポジトリとローカルリポジトリの関係

GitLabを使う上で最も基本的なのは、リモートリポジトリ（GitLab上）とローカルリポジトリ（自分のPC上）の間でコードをやり取りすることです。

  • クローン (Clone): リモートリポジトリのコードを、初めて自分のローカル環境にコピーしてローカルリポジトリを作成する操作です。
  • プッシュ (Push): ローカルリポジトリで行ったコミットを、リモートリポジトリに送信して反映させる操作です。
  • プル (Pull): リモートリポジトリの最新の変更（他の人がプッシュしたコミットなど）を、自分のローカルリポジトリに取り込む操作です。フェッチ(Fetch)でリモートの変更を取得し、マージ(Merge)でローカルに取り込む、という二段階の操作を合わせたものです。

図解：リモートとローカルのやり取り

+-----------------+ +-----------------+
| ローカルリポジトリ | | リモートリポジトリ |
| (あなたのPC上) | | (GitLabサーバー上) |
+-----------------+ +-----------------+
| ^
| clone (初回取得) |
|<---------------------------|
| |
| push (ローカル->リモートへ) |
|--------------------------->|
| |
| pull (リモート->ローカルへ) |
|<---------------------------|
| |

この図は、クローン、プッシュ、プルといった基本的な操作によって、ローカルリポジトリとリモートリポジトリ間でコードが同期される様子を表しています。

これらのGitの基本的な概念を理解しておけば、GitLabを使った作業がスムーズに進められるでしょう。

GitLab環境の準備

GitLabを利用するための最初のステップは、GitLabのアカウントを作成し、コードを管理するためのプロジェクトを準備することです。

GitLabアカウントの作成

GitLab.comを利用する場合、Webブラウザからアクセスし、アカウントを作成します。

  1. GitLab.com にアクセス: https://gitlab.com/ にアクセスします。
  2. サインアップ: 「Register now」や「Get started for free」といったボタンをクリックし、必要情報を入力してアカウントを作成します。メールアドレス、ユーザー名、パスワードなどを設定します。GitHubやGoogleアカウントなどと連携してサインアップすることも可能です。
  3. アカウント設定: サインアップ後、プロフィール設定などを完了します。

グループとプロジェクトの作成

GitLabでは、コードは「プロジェクト」として管理されます。複数の関連するプロジェクトをまとめるために「グループ」を作成することができます。チームで開発を行う場合は、まずチームのグループを作成し、その中に各プロジェクトを作成するのが一般的です。

グループの作成

  1. GitLabにログインします。
  2. 画面左上のメニューアイコンをクリックし、「Groups」>「Your groups」>「New group」と進みます。
  3. 「Create group」ページで、以下の情報を入力します。
    • Group name: グループの名前 (例: MyTeamDevelopment)
    • Group URL: グループのURLの一部となります (自動入力されることが多いですが、任意に変更可能)
    • Group description (Optional): グループの説明
    • Visibility level: 誰がこのグループを見れるか設定します (Private, Internal, Public)
    • Role: このグループを何に使うか選択します (今回は「Developing software」など)
  4. 「Create group」ボタンをクリックします。

これでチームのグループが作成されました。次に、このグループの中にプロジェクトを作成します。

プロジェクトの作成

  1. 作成したグループのページに移動します。
  2. 「New project」ボタン、または左上のメニューから「Create new project/repository」を選択します。

  3. 「New project」ページで、いくつかの選択肢があります。

    • Create blank project: 完全に空のリポジトリを作成します。
    • Create from template: 既存のテンプレート（Webサイト、Ruby on Railsなど）からプロジェクトを作成します。
    • Import project: GitHubや他のサービスから既存のプロジェクトをインポートします。
    • CI/CD for external repo: 外部のリポジトリ（GitHubなど）に対してGitLab CI/CDのみを使用する場合に選択します。

    今回は最も一般的な「Create blank project」を選択します。
    4. 以下の情報を入力します。
    * Project name: プロジェクトの名前 (例: my-first-web-app)
    * Project slug: プロジェクトのURLの一部となります (自動入力)
    * Group or user: プロジェクトを作成する場所（先ほど作成したグループを選択）
    * Project description (Optional): プロジェクトの説明
    * Visibility Level: プロジェクトの公開範囲を設定します (Private, Internal, Public)。通常はPrivateを選択します。
    * Initialize repository with a README: プロジェクト作成時にREADMEファイルを含めるかどうか。チェックを入れると、プロジェクト作成直後からクローンできるようになります。最初はチェックを入れておくのがおすすめです。
    5. 「Create project」ボタンをクリックします。

これで、GitLab上にコードを管理するための新しいプロジェクト（リモートリポジトリ）が作成されました。

図解：グループとプロジェクトの構造

+--------------------------+
| GitLab.com |
| |
| +----------------------+ |
| | MyTeamDevelopment グループ | |
| | | |
| | +--------------------+ | |
| | | my-first-web-app PJT | | |
| | | | | |
| | | .git (リポジトリ履歴) | | |
| | | コードファイル | | |
| | +--------------------+ | |
| | | |
| | +--------------------+ | |
| | | another-service PJT| | |
| | | ... | | |
| | +--------------------+ | |
| +----------------------+ |
| |
| +----------------------+ |
| | YourPersonalProject | |
| | ... | |
| +----------------------+ |
+--------------------------+

この図は、GitLabの中に複数のグループや個人プロジェクトが存在し、グループの中にさらに複数のプロジェクトが階層構造で含まれる様子を示しています。

ローカル開発環境の設定

GitLabで作成したリモートリポジトリと連携するためには、自分のローカルコンピュータにGitをインストールし、必要に応じて認証設定を行う必要があります。

Gitのインストール

  • Windows: Gitの公式ウェブサイト (https://git-scm.com/) からインストーラーをダウンロードして実行します。Git Bashというコマンドラインツールも一緒にインストールされます。
  • macOS: Homebrewを使っている場合は brew install git でインストールできます。または、XcodeをインストールするとGitも含まれます。
  • Linux: 各ディストリビューションのパッケージマネージャー (sudo apt install git for Debian/Ubuntu, sudo yum install git for Fedora/CentOSなど) を使ってインストールします。

インストール後、ターミナルやコマンドプロンプトで git --version と入力し、バージョン情報が表示されればインストール成功です。

Gitの初期設定

Gitをインストールしたら、最低限、コミットに表示されるユーザー名とメールアドレスを設定しておきましょう。

bash
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

GitLabへの認証設定 (SSHキーがおすすめ)

ローカルからGitLabのリモートリポジトリに対して git push や git pull といった操作を行う際には、認証が必要です。パスワード認証も可能ですが、より安全で便利なSSHキー認証が推奨されます。

SSHキー認証の仕組みは以下の通りです：

  1. ローカルコンピュータでSSHキーペア（公開鍵と秘密鍵）を生成します。
  2. 生成した公開鍵をGitLabアカウントに登録します。
  3. ローカルからSSH経由でGitLabにアクセスする際に、GitLabはローカルから送られてきた公開鍵に対応する秘密鍵を持っているかを確認し、認証を行います。秘密鍵はローカルに安全に保管されます。

SSHキーの生成手順:

  1. ターミナルやGit Bashを開きます。

  2. 以下のコマンドを実行します（メールアドレスはGitLabに登録しているものを使うと分かりやすいです）。

    bash
    ssh-keygen -t rsa -b 4096 -C "[email protected]"

    • -t rsa: 暗号化の種類としてRSAを指定します。
    • -b 4096: キーの長さを指定します（推奨）。
    • -C "...": コメントです。メールアドレスなどを入れておくと後でどのキーか分かりやすくなります。
    • キーを保存する場所を聞かれます。特に希望がなければデフォルトのままEnterを押します（~/.ssh/id_rsa など）。
    • パスフレーズの設定を聞かれます。キー使用時の追加のセキュリティとして設定できます。設定する場合は入力し、確認のために再度入力します。設定しない場合はそのままEnterを2回押します（セキュリティ上は設定推奨ですが、今回は省略も可）。
    • 公開鍵と秘密鍵が指定した場所に生成されます（例: ~/.ssh/id_rsa.pub が公開鍵、~/.ssh/id_rsa が秘密鍵）。

GitLabへの公開鍵の登録:

  1. 生成した公開鍵ファイル（.pub で終わるファイル、例: ~/.ssh/id_rsa.pub）の内容をテキストエディタなどで開いて、すべてコピーします。
    • Windows (Git Bash): cat ~/.ssh/id_rsa.pub
    • macOS/Linux: cat ~/.ssh/id_rsa.pub
  2. GitLabにログインします。
  3. 画面右上のユーザーアイコンをクリックし、「Settings」を選択します。
  4. 左側のメニューから「SSH Keys」を選択します。
  5. 「Key」というテキストエリアにコピーした公開鍵の内容を貼り付けます。
  6. 「Title」にはこのキーの名前（例: MyLaptop SSH Key）を入力します。
  7. 「Expires at (Optional)」では有効期限を設定できます。
  8. 「Add key」ボタンをクリックします。

これで、ローカルコンピュータからSSHプロトコルを使ってGitLabに認証なしでアクセスできるようになりました。Gitリポジトリのクローンやプッシュ/プルは、SSH形式のURL ([email protected]:group-name/project-name.git) を使うことになります。

図解：SSHキー認証の流れ

+-----------------+ +-----------------+
| ローカルPC | | GitLabサーバー |
| | | |
| +-------------+ | | +-------------+ |
| | 秘密鍵 (id_rsa) | | | | 公開鍵リスト | |
| +-------------+ | | | +-----------+ | |
| | | | | あなたの公開鍵| |
| SSH接続要求 ---->| | | +-----------+ | |
| | | | | ... | | |
| |<---------+ | +-------------+ |
| 認証成功！ | | |
+-----------------+ +-----------------+

この図は、ローカルPCの秘密鍵とGitLabサーバーに登録された公開鍵がペアとなり、SSH接続時の認証がパスワードなしで行われる仕組みを示しています。

プロジェクトの基本操作：ローカルからリモートへ

GitLab上にプロジェクト（リモートリポジトリ）を作成し、ローカル環境の準備ができたら、いよいよコードを置いて操作してみましょう。

新しいプロジェクトを始める (ローカルにまだコードがない場合)

GitLabで「Initialize repository with a README」にチェックを入れてプロジェクトを作成した場合、既にリモートリポジトリにはREADMEファイルが存在します。このリモートリポジトリをローカルに持ってきて作業を開始します。

  1. プロジェクトのSSH URLをコピー: GitLab上で作成したプロジェクトのページを開きます。画面中央付近にある「Clone」ボタンをクリックすると、SSH形式とHTTPS形式のURLが表示されます。「Clone with SSH」の下に表示されているURL（[email protected]:group-name/project-name.git の形式）をコピーします。

  2. ローカルにクローン: ターミナルやGit Bashを開き、プロジェクトのファイルを置きたいディレクトリに移動します。そして、以下のコマンドを実行します。

    bash
    git clone [email protected]:group-name/project-name.git

    group-name/project-name の部分は、先ほどコピーしたURLに合わせて置き換えてください。例えば、[email protected]:myteamdevelopment/my-first-web-app.git のようになります。

    このコマンドを実行すると、指定したURLのリモートリポジトリの内容が、ローカルの現在のディレクトリに新しいフォルダ（プロジェクト名と同じ名前）としてコピーされます。これがローカルリポジトリになります。
    3. ディレクトリ移動: クローンしてできたプロジェクトのディレクトリに移動します。

    bash
    cd my-first-web-app

    このディレクトリ内でGitの操作を行います。.git という隠しフォルダが作成されており、ここにリポジトリのすべての履歴情報が格納されています。

図解：新規プロジェクトの開始 (clone)

+-----------------+ +-----------------+
| ローカルPC | | GitLabサーバー |
| | | |
| (空のディレクトリ) | | プロジェクトA (リモート) |
| | | +---------------+ |
| git clone コマンド | | | README.md | |
|----------------->| | | .git | |
| | | +---------------+ |
| | | |
| |<---------| (プロジェクトAの内容をコピー)
| | | |
| +---------------+ | | |
| | プロジェクトA(ローカル) | | | |
| | +-----------+ | | | |
| | | README.md | | | | |
| | | .git | | | | |
| | +-----------+ | | | |
+-----------------+ +-----------------+

この図は、GitLabにあるリモートリポジトリの内容を git clone コマンドによってローカルにコピーし、ローカルリポジトリを準備する様子を示しています。

既存のコードをGitLabで管理する (ローカルに既にコードがある場合)

既にローカルで開発しているプロジェクトのコードがあり、それを新しく作成したGitLabのリモートリポジトリで管理したい場合は、以下の手順を行います。GitLabでプロジェクトを作成する際に「Initialize repository with a README」のチェックは外しておいてください。

  1. 既存のプロジェクトディレクトリに移動: ターミナルやGit Bashを開き、管理したいコードがあるプロジェクトのルートディレクトリに移動します。

  2. ローカルリポジトリの初期化: このディレクトリをGitリポジトリにするために、以下のコマンドを実行します。

    bash
    git init

    これにより、.git という隠しフォルダが作成され、現在のディレクトリがローカルGitリポジトリとして初期化されます。
    3. 最初のコミット: 現在のファイルの状態を最初のコミットとして記録します。

    bash
    git add .
    git commit -m "Initial commit"

    • git add .: 現在のディレクトリにあるすべてのファイルとディレクトリを、次のコミットの対象としてステージングエリアに追加します。
    • git commit -m "...": ステージングエリアに追加された変更をコミットとして記録します。-m オプションの後にコミットメッセージを記述します。
    • リモートリポジトリの追加: GitLabで作成した空のプロジェクトを、このローカルリポジトリの「リモート」として設定します。GitLabプロジェクトページの「Clone」ボタンの下にあるSSH URLをコピーし、以下のコマンドを実行します。

    bash
    git remote add origin [email protected]:group-name/project-name.git

    • git remote add: リモートリポジトリを追加するコマンドです。
    • origin: 追加するリモートリポジトリに付ける名前です。慣習的に最初のメインのリモートは origin とします。
    • [email protected]:...: リモートリポジトリのURLです。
    • リモートへのプッシュ: ローカルリポジトリのコードと履歴を、設定したリモートリポジトリに送信します。

    bash
    git push -u origin main

    • git push: ローカルのコミットをリモートに送信します。
    • -u origin main: ローカルの main ブランチを、リモートの origin という名前のリポジトリの main ブランチにプッシュします。さらに、今後の git pull や git push の際に、ローカルの main ブランチがリモートの origin/main ブランチと関連付けられるよう設定します（次回以降 git push だけで済むようになります）。もしローカルのメインブランチが master という名前の場合は git push -u origin master となります。

これで、ローカルにあったコードがGitLabのリモートリポジトリにプッシュされ、管理が開始されます。GitLabのプロジェクトページを更新すると、ファイルが表示されているはずです。

図解：既存コードの管理開始 (init, add, commit, remote, push)

+-----------------+ +-----------------+
| ローカルPC | | GitLabサーバー |
| | | |
| +---------------+ | | プロジェクトB (空のリモート) |
| | 既存コード | | | |
| | (まだGit管理なし) | | | |
| +---------------+ | +-----------------+
| ^
| git init |
| |
| +---------------+ | | |
| | 既存コード | | | |
| | .git (初期化済) | | | |
| +---------------+ | | | |
| |
| git add . |
| git commit -m "Initial" |
| |
| +---------------+ | | |
| | 既存コード | | | |
| | .git (最初のコミット済)| | | |
| +---------------+ | | | |
| |
| git remote add origin ... | (リモートURLを設定)
| |
| git push -u origin main | (ローカルコミットを送信)
|--------------------------->|
| |
| v
+-----------------+ +-----------------+
| プロジェクトB(ローカル) | | プロジェクトB(リモート) |
| (mainブランチにコード有)| | (mainブランチにコード有)|
+-----------------+ +-----------------+

この図は、既存のコードディレクトリを git init でローカルリポジトリにし、ファイルを追加・コミットし、GitLabのリモートリポジトリを登録して、最初のコミットをプッシュするまでの流れを示しています。

ファイルの追加・変更とコミット

ローカルリポジトリでコードを開発する際の基本的なサイクルは「変更 -> ステージ -> コミット」です。

  1. ファイルの変更: プロジェクトディレクトリ内でコードを編集したり、新しいファイルを作成したりします。

  2. 変更状態の確認: どのファイルが変更されたか、Gitがどのように認識しているかを確認できます。

    bash
    git status

    このコマンドは、変更されたファイル、新しく作成されたファイル、削除されたファイルなどを表示し、それらがコミット対象になっているか（ステージされているか）も示します。
    3. 変更をステージングエリアに追加: コミットとして記録したい変更を選んで、ステージングエリアに移動します。

    bash
    git add <ファイル名> # 特定のファイルのみを追加
    git add . # 現在のディレクトリ以下のすべての変更を追加

    ステージングエリアは、「次にコミットする変更の準備場所」です。git add した変更だけが次のコミットに含まれます。
    4. 変更をコミット: ステージングエリアに追加された変更をコミットとして記録します。

    bash
    git commit -m "簡潔な変更内容の要約"

    コミットメッセージは、なぜその変更を行ったのか、どのような変更なのかを分かりやすく記述します。一行目は50文字程度で簡潔な要約を書き、必要であれば空行の後に詳細を記述するのが良いとされています。

この「変更 -> add -> commit」のサイクルを繰り返しながら開発を進めます。

図解：コミットサイクルの状態遷移

+-----------------+
| Working Directory | (作業中のファイル群)
+-----------------+
| (ファイルの変更・作成・削除)
v
+-----------------+
| Staging Area | (次にコミットする変更の準備場所)
+-----------------+
| git add <ファイル名> / .
v
+-----------------+
| Local Repository| (変更履歴がコミットとして記録される場所)
| (.gitフォルダ) |
+-----------------+
| git commit -m "..."
v
(新しいコミットが履歴に追加される)

この図は、コードの変更が「作業ディレクトリ」で行われ、git add で「ステージングエリア」に移され、git commit で「ローカルリポジトリ」に正式なコミットとして記録される流れを示しています。

リモートへのプッシュ (git push)

ローカルリポジトリでコミットした変更を、GitLabのリモートリポジトリに反映させます。

bash
git push origin main

  • git push: ローカルのコミットをリモートに送信するコマンドです。
  • origin: 送信先のリモートリポジトリの名前です（git remote add で設定したもの）。
  • main: 送信するローカルブランチの名前です。

このコマンドを実行すると、ローカルの main ブランチの新しいコミットが、リモートの origin リポジトリの main ブランチにアップロードされます。他のチームメンバーは、この変更をプルすることで自分のローカルリポジトリに取り込むことができます。

リモートからのプル (git pull)

他のチームメンバーがリモートリポジトリにプッシュした最新の変更を、自分のローカルリポジトリに取り込みます。

bash
git pull origin main

  • git pull: リモートの変更を取得し、ローカルのブランチにマージするコマンドです。
  • origin: 変更を取得するリモートリポジトリの名前です。
  • main: 変更を取得するリモートブランチの名前と、マージするローカルブランチの名前です。

このコマンドは、実質的に以下の2つのコマンドを連続して実行しています。

  1. git fetch origin main: リモートの origin リポジトリから main ブランチの最新のコミット情報を取得しますが、ローカルの作業ディレクトリやブランチにはまだ反映しません。
  2. git merge origin/main: 取得したリモートの main ブランチの変更（origin/main という名前で参照されます）を、現在のローカルブランチにマージします。

git pull を実行する前に git fetch だけで変更内容を確認したり、git status で現在の状態を確認したりする習慣をつけるのも良いでしょう。

チーム開発のためのブランチ操作

Gitのブランチ機能は、チーム開発において非常に強力です。各開発者が独立した作業を進め、後でそれらを安全に統合することができます。

ブランチの作成と切り替え

新しい機能開発やバグ修正を始める際には、通常メインブランチ（mainなど）から新しいブランチを作成します。

  1. 新しいブランチの作成:

    bash
    git branch feature/add-user-profile

    このコマンドは main ブランチの現在のコミットから feature/add-user-profile という名前の新しいブランチを作成しますが、現在の作業ブランチは main のままです。
    2. 作業ブランチの切り替え: 作成した新しいブランチで作業を行うために、そのブランチに切り替えます。

    bash
    git checkout feature/add-user-profile

    または、新しいブランチを作成と同時にそのブランチに切り替える場合は、以下のコマンドが便利です。

    bash
    git checkout -b feature/add-user-profile

    • -b オプションは、指定した名前のブランチが存在しない場合に新しく作成するという意味です。

作業ブランチを切り替えると、ローカルのファイル群がそのブランチの最新のコミットの状態に切り替わります。ここで行う変更やコミットは、切り替えたブランチ上で行われることになります。

図解：ブランチの作成と切り替え

+-----------------+
| コミット履歴 (main) |
| A -- B -- C (HEAD: main)
+-----------------+
| git branch feature-X
v
+-----------------+
| コミット履歴 |
| A -- B -- C (HEAD: main)
| \
| feature-X
+-----------------+
| git checkout feature-X
v
+-----------------+
| コミット履歴 |
| A -- B -- C
| \
| feature-X (HEAD: feature-X)
+-----------------+

この図は、コミット C の時点で main ブランチから feature-X ブランチが作成され、その後 git checkout によって作業対象が feature-X ブランチに切り替わる様子を示しています。HEAD は現在作業しているブランチやコミットを指します。

ブランチのプッシュ

ローカルで新しいブランチを作成し、そのブランチ上でコミットを重ねたら、そのブランチをGitLabのリモートリポジトリにもプッシュします。

bash
git push origin feature/add-user-profile

初めてそのブランチをプッシュする場合、ローカルブランチとリモートブランチを関連付けるために -u オプションを付けてプッシュすることが推奨されます。

bash
git push -u origin feature/add-user-profile

これにより、ローカルの feature/add-user-profile ブランチが、リモートの origin リポジトリの feature/add-user-profile ブランチに関連付けられます。次回以降はこのブランチで git push や git pull を行う際にブランチ名を省略できるようになります。

他のブランチの取り込み (git merge)

あるブランチで行った変更を別のブランチに取り込むには、マージを行います。例えば、feature/add-user-profile ブランチで開発した機能を main ブランチに取り込みたい場合などです。

  1. マージ先のブランチに切り替え: 変更を取り込みたい側のブランチに移動します。今回は main ブランチです。

    bash
    git checkout main
    2. リモートの最新変更を取り込み: マージする前に、マージ先のブランチがリモートの最新の状態であることを確認するためにプルしておきます。

    bash
    git pull origin main
    3. ブランチをマージ: 現在いるブランチ（main）に、指定したブランチ（feature/add-user-profile）の変更を取り込みます。

    bash
    git merge feature/add-user-profile

    マージが成功すると、feature/add-user-profile ブランチでのコミット履歴が main ブランチの履歴に取り込まれます。マージの仕方には「Fast-forward マージ」と「3-way マージ」がありますが、ここでは詳しい説明は割愛します。

図解：マージの流れ

+-----------------+
| コミット履歴 |
| A -- B -- C (main)
| \
| D -- E (feature-X)
+-----------------+
| git checkout main
v
+-----------------+
| コミット履歴 |
| A -- B -- C (HEAD: main)
| \
| D -- E (feature-X)
+-----------------+
| git merge feature-X
v (衝突がなければ自動マージ)
+-----------------+
| コミット履歴 (マージ後) |
| A -- B -- C -- F (HEAD: main) <-- F はマージコミット
| \ /
| D -- E
+-----------------+

この図は、main と feature-X という2つのブランチがあり、main に切り替えた後、git merge feature-X を実行することで、feature-X の変更が main ブランチに取り込まれ、マージコミット F が作成される様子を示しています。

コンフリクトの解消

複数のブランチで同じファイルの同じ箇所を同時に変更した場合など、Gitが自動的にマージできない状態になることがあります。これを「コンフリクト（衝突）」と呼びます。

コンフリクトが発生すると、Gitはマージを中断し、どのファイルで衝突が起きているかを教えてくれます。衝突したファイルを開くと、Gitが衝突箇所を特殊なマーカーで示しています。

“`
<<<<<<< HEAD
// mainブランチでの変更
int x = 10;
=======
// featureブランチでの変更
int x = 20;

feature/add-user-profile
“`

  • <<<<<<< HEAD: 現在のブランチ（マージ先、例: main）の変更の開始
  • =======: 変更の区切り
  • >>>>>>> feature/add-user-profile: マージ元ブランチ（例: feature/add-user-profile）の変更の終了

コンフリクトの解消手順:

  1. 衝突したファイルを開き、Gitが挿入したマーカーと、両方のブランチの変更内容を確認します。
  2. どちらか一方の変更を採用するか、両方の変更を組み合わせるか、あるいは全く新しいコードを書くかして、衝突箇所を修正します。マーカー (<<<<<<<, =======, >>>>>>>) はすべて削除します。
  3. ファイルを保存します。

  4. 変更をステージングエリアに追加します。

    bash
    git add <コンフリクトを解消したファイル名>
    5. マージを完了するためにコミットします。コンフリクト解消時のマージコミットメッセージは、Gitが自動生成してくれます。必要に応じて編集し、コミットを完了します。

    bash
    git commit

    エディタが立ち上がるので、メッセージを編集して保存・終了します。

コンフリクト解消はGitを使う上で避けて通れない道です。落ち着いて手順を踏めば必ず解消できます。

ブランチ戦略 (Git Flow, GitLab Flowなど)

チームで効率的に開発を進めるためには、どのようなルールでブランチを作成・運用していくかという「ブランチ戦略」を事前に決めておくことが重要です。代表的な戦略としては、Git FlowやGitLab Flowなどがあります。

  • Git Flow: 開発(develop)、リリース(release)、ホットフィックス(hotfix)などの長期的なブランチと、機能開発(feature)などの短期的なブランチを使い分ける、比較的複雑な戦略です。
  • GitLab Flow: main (または master) ブランチを安定版とし、機能開発やバグ修正はすべてfeature ブランチで行い、マージリクエストを通じて main にマージするという、Git FlowよりもシンプルでGitLabの機能を活用しやすい戦略です。本記事で説明しているマージリクエストのフローは、GitLab Flowに基づいています。

プロジェクトの規模やチームの特性に合わせて、適切なブランチ戦略を選択し、チーム内で共有することが大切です。

GitLabを使ったコラボレーション

GitLabは、単なるGitリポジトリホスティングサービスではなく、チームでの開発を支援する様々なコラボレーション機能を提供しています。ここでは、その中でも特に重要な「マージリクエスト」と「課題」について詳しく解説します。

マージリクエスト (Merge Request – MR)

マージリクエスト（他サービスではプルリクエストと呼ばれることが多い）は、あるブランチの変更内容を別のブランチ（例えば、開発ブランチをメインブランチに）に取り込むことを提案し、その変更について議論、レビュー、テスト、そして承認を行うための仕組みです。チーム開発の中心となる機能と言えます。

図解：マージリクエストのワークフロー

+-----------------+ +-----------------+ +-----------------+
| 開発者A (ローカル) | | GitLabサーバー | | 開発者B (レビュー担当) |
+-----------------+ +-----------------+ +-----------------+
| ^ ^
| | |
| 1. 機能ブランチ作成・開発 | |
| (git branch, checkout, add, commit) |
| | |
| 2. ブランチをリモートへプッシュ | |
|--------------------------->| |
| | |
| | 3. GitLabでMerge Request作成 |
| | (例: feature/login -> main) |
| | |
| | 4. レビュー依頼 (開発者Bへ) |
| |--------------------------->|
| | | 5. MR内容確認、コードレビュー
| | | + コメント投稿
| | |<------------------
| | |
| | 6. CI/CDパイプライン自動実行 | (自動テスト、ビルドなど)
| | |
| |<---------------------------| (CI結果、レビューコメント)
| | |
|<---------------------------| (コメント、レビュー結果など) |
| | |
| 7. 必要に応じてコード修正、プッシュ (MRに自動反映) |
|--------------------------->| |
| | |
| | 8. レビュー担当者が承認 |
| |--------------------------->|
| | |
| | 9. マージ実行 | (MR作成者またはメンテナー)
| |---------------------------> (mainブランチ更新)
| | |

この図は、開発者が新しいブランチで作業し、それをリモートにプッシュした後、GitLab上でマージリクエストを作成し、レビュー担当者がコードレビューを行い、CI/CDが自動実行され、最終的に変更がメインブランチにマージされるまでの一連のプロセスを示しています。

MRの作成方法

ローカルで新しいブランチをリモートにプッシュすると、GitLabのプロジェクトページの上部や、特定のブランチページに「Create merge request」というボタンが表示されることがあります。または、左側メニューの「Merge requests」から「New merge request」をクリックして作成することもできます。

作成時には、以下の情報を設定します。

  • Source branch: マージしたい変更が含まれているブランチ（開発ブランチ）
  • Target branch: 変更を取り込みたいブランチ（マージ先、例: main）
  • Title: マージリクエストの目的を簡潔に表すタイトル (例: Add user profile page)
  • Description: 変更内容の詳細、関連する課題番号、考慮事項などを記述します。
  • Assignee: このMRの担当者（マージする責任者）を割り当てます。
  • Reviewer: コードレビューを依頼したいメンバーを割り当てます。
  • Labels: MRに関連するラベル（機能、バグ、進捗状況など）を設定します。
  • Milestone: 関連するマイルストーン（開発期間や目標）を設定します。

コードレビュー

マージリクエストの最も重要な機能の一つがコードレビューです。レビュー担当者は、提案された変更のコード差分を確認し、コメントを付けたり、質問したり、改善点を提案したりします。

GitLabのMRページでは、変更されたファイルの一覧が表示され、それぞれのファイルでコードの追加、削除、変更が色分けされて表示されます。特定のコード行にコメントを残すことも可能です。

承認 (Approvals)

プロジェクトの設定によっては、マージを行うために特定の人数または特定の権限を持つメンバーからの承認が必要となるように設定できます。レビュー担当者がコードを確認し問題がなければ「Approve」ボタンをクリックして承認を示します。

CI/CDとの連携

GitLab CI/CDを設定している場合、マージリクエストが作成されたり、そのブランチに新しいコミットがプッシュされたりするたびに、自動的にCI/CDパイプライン（テスト、ビルドなど）が実行されます。パイプラインの結果（成功/失敗）はMRページに表示され、マージが可能かどうかの判断材料となります。テストが失敗しているMRはマージできないように設定することも可能です。

MRのマージ

すべてのレビューが完了し、承認が得られ、CI/CDパイプラインも成功したら、マージする準備が整います。マージ権限を持つユーザー（通常は開発者本人か、プロジェクトのメンテナー）がMRページ下部にある「Merge」ボタンをクリックしてマージを実行します。

マージオプションとして、以下を選択できます。

  • Squash commits: 開発ブランチでの複数のコミットを一つにまとめてマージします。履歴がスッキリします。
  • Remove source branch: マージ完了後に、マージ元となったブランチ（開発ブランチ）を自動的に削除します。不要なブランチが残りません。

MRのクローズ

マージが完了したマージリクエストは自動的にクローズされます。また、その変更が不要になった場合などは、手動でクローズすることも可能です。

課題 (Issues)

GitLabの課題（Issues）機能は、開発プロジェクトにおけるタスク、バグ報告、機能要望、質問などを追跡・管理するためのツールです。これは、コードの変更履歴とは別に、開発に関する様々な事項を管理する場所です。

図解：課題のワークフロー（一例）

+-----------------+ +-----------------+
| チームメンバーA | | GitLabプロジェクト |
+-----------------+ +-----------------+
| ^
| 1. バグ報告/機能要望として課題を作成 |
|--------------------------->| (課題 #123)
| |
| | 2. 課題の詳細確認、担当者(開発者B)アサイン
| | ラベル、マイルストーン設定
| |---------------------------> (開発者Bへ通知)
| |
| | 3. 課題 #123 に基づき開発ブランチ作成、開発
| | コミットメッセージに "Fix #123" などと記載
| |
| | 4. マージリクエスト作成 (feature/fix-bug-123 -> main)
| | MRの説明に "Closes #123" と記載
| |---------------------------> (MR #45)
| |
| | 5. MR #45 のレビュー、マージ
| |
| v
+-----------------+ +-----------------+
| 開発者B (ローカル) | | 課題 #123 が自動的にクローズ |
+-----------------+ +-----------------+

この図は、チームメンバーが課題を作成し、担当者が割り当てられ、その課題を解決するための開発が進められ、マージリクエストと連携して課題が自動的にクローズされるまでの一連の流れを示しています。

課題の作成と管理

プロジェクトページから左側メニューの「Issues」>「List」>「New issue」をクリックして課題を作成します。

  • Title: 課題の内容を簡潔に表すタイトル
  • Description: 課題の詳細、再現手順（バグの場合）、要件（機能要望の場合）などを記述します。Markdown形式で記述可能です。
  • Assignee: 誰がこの課題を担当するかを割り当てます。
  • Labels: 課題の種類（bug, feature, questionなど）、優先度、担当チームなどを分類するためのラベルを設定します。
  • Milestone: この課題をいつまでに完了させるか、関連するマイルストーンを設定します。
  • Due Date: 課題の期限日を設定します。

作成された課題は一覧表示され、担当者やラベルなどでフィルタリングして確認できます。課題ページでは、コメントで議論を行ったり、関連するMRやコミットと連携させたりすることができます。

MRとの連携 (MRからIssueを閉じる)

GitLabでは、マージリクエストをマージした際に、関連する課題を自動的にクローズする機能があります。マージリクエストのDescriptionやコミットメッセージに特定のキーワードと課題番号を含めるだけです。

例：

  • マージリクエストのDescriptionに Closes #123 と記述する
  • コミットメッセージに Fixes #123 と記述する

これらのキーワード（Closes, Fixes, Resolves, Implementsなど）の後に課題番号（例: #123）を記述してマージすると、そのMRがマージされた際に指定した課題が自動的に「Closed」状態になります。これにより、開発と課題管理を密接に連携させることができます。

Wiki

各GitLabプロジェクトにはWiki機能が含まれています。プロジェクトに関するドキュメント（設計資料、環境構築手順、意思決定プロセスなど）をMarkdown形式で作成・管理できます。Gitリポジトリとして管理されるため、変更履歴も追跡可能です。

スニペット (Snippets)

スニペット機能を使うと、プロジェクト全体や特定のユーザーに紐付かない短いコード片やテキストを共有・保存できます。「特定の技術的なメモ」や「よく使う設定ファイルの一部」などを簡単に共有したい場合に便利です。

GitLabの強力な機能：CI/CD (Continuous Integration/Continuous Deployment)

GitLabの最大の特徴であり、現代のDevOpsにおいて最も重要な機能の一つがCI/CDです。CI/CDは、ソフトウェアの変更をより迅速かつ安全に、そして継続的にユーザーに届けられるようにするためのプラクティスです。

  • CI (Continuous Integration – 継続的インテグレーション): 開発者がコードの変更を頻繁にメインブランチにマージし、そのたびに自動的にビルドやテストを実行して、問題があればすぐに発見・修正できるようにするプラクティスです。
  • CD (Continuous Deployment/Delivery – 継続的デプロイ/デリバリー): CIで検証されたコードを、自動的に本番環境やステージング環境にデプロイできるようにするプラクティスです。

GitLab CI/CDは、プロジェクトのリポジトリに置かれた .gitlab-ci.yml という設定ファイルに基づいて動作します。

.gitlab-ci.yml ファイルの基本構造

.gitlab-ci.yml ファイルはYAML形式で記述され、CI/CDパイプラインの定義を行います。このファイルはリポジトリのルートディレクトリに配置します。

基本的な構成要素：

  • Stages: パイプライン全体における処理のフェーズを定義します。ジョブは指定されたステージの順序で実行されます。一般的なステージとしては build, test, deploy などがあります。
  • Jobs: 実際に実行される個々の処理単位です。各ジョブはどのステージに属するか、どのスクリプトを実行するかなどを定義します。同じステージ内のジョブは、特に依存関係を指定しない限り並列で実行されます。

図解：CI/CDパイプラインの概念

+-----------------+
| git push |
+-----------------+
|
v
+-----------------+
| GitLab CI/CD |
| (パイプライン起動) |
+-----------------+
|
v
+-----------------+ +-----------------+ +-----------------+
| Stage: Build | ---->| Stage: Test | ---->| Stage: Deploy |
| +-------------+ | | +-------------+ | | +-------------+ |
| | Job: compile| | | | Job: unit-test| | | | Job: deploy | |
| +-------------+ | | +-------------+ | | +-------------+ |
| | Job: package| | | | Job: lint | | | |
| +-------------+ | | +-------------+ | | |
+-----------------+ +-----------------+ +-----------------+

この図は、コードがプッシュされるとGitLab CI/CDパイプラインが起動し、定義されたステージ（ここでは Build, Test, Deploy）が順番に実行され、各ステージに含まれるジョブが並列または直列に実行される様子を示しています。

簡単なCI/CDパイプラインの例

ウェブサイトのコードをチェック（Lint）、テスト、そして静的サイトホスティングサービスにデプロイする簡単な .gitlab-ci.yml の例を見てみましょう。

“`yaml
stages:
– lint
– test
– deploy

lint-job:
stage: lint
script:
– echo “Running lint check…”
# 例: JavaScriptのコードをESLintでチェックするコマンド
# – npm install eslint
# – npx eslint .

test-job:
stage: test
script:
– echo “Running tests…”
# 例: Jestでテストを実行するコマンド
# – npm install jest
# – npm test

deploy-job:
stage: deploy
script:
– echo “Deploying to staging…”
# 例: デプロイスクリプトの実行
# – ./deploy_to_staging.sh
only:
– main # mainブランチへのマージ時のみ実行
“`

解説：

  • stages: で lint, test, deploy という3つのステージを定義しています。パイプラインはこれらのステージをこの順序で実行します。
  • lint-job:, test-job:, deploy-job: はそれぞれジョブの名前です。任意の名前を付けられます。
  • stage: でそのジョブがどのステージに属するかを指定します。
  • script: でそのジョブで実行したいコマンドを定義します。複数のコマンドは順番に実行されます。ここでは簡単な echo コマンドを例としていますが、実際にはコードのビルド、テスト実行、デプロイコマンドなどを記述します。
  • only: は、特定の条件を満たす場合にのみジョブを実行するための設定です。この例では deploy-job は main ブランチへの変更があった場合（マージなど）のみ実行されます。他のブランチへのプッシュでは実行されません。

このファイルをリポジトリのルートに .gitlab-ci.yml という名前で保存し、GitLabにプッシュすると、自動的にパイプラインが起動します。パイプラインの実行状況は、左側メニューの「CI/CD」>「Pipelines」から確認できます。

図解：パイプライン実行画面のイメージ (テキスト表現)

+--------------------------------------------------+
| Pipelines |
| Project: my-first-web-app |
| |
| +----------------------------------------------+ |
| | Pipeline #56 (triggered by push on main) | |
| | Status: Passed | |
| | Commit: abcdef12 (Add user profile page) | |
| | User: Your Name | |
| +----------------------------------------------+ |
| | Stages: | |
| | +-----------+ +-----------+ +-----------+ | |
| | | lint | | test | | deploy | | |
| | | (Passed) | | (Passed) | | (Passed) | | |
| | +-----+-----+ +-----+-----+ +-----+-----+ | |
| | | | | | |
| | +-----v-----+ +-----v-----+ +-----v-----+ | |
| | | lint-job | | test-job | | deploy-job| | |
| | | (Passed) | | (Passed) | | (Passed) | | |
| | +---------+ | +---------+ | +---------+ | | |
| +-------------+-------------+-------------+--+ |
| | ... Other Pipelines ... | |
+--------------------------------------------------+

この図は、GitLabのパイプライン一覧画面のイメージを示しています。各パイプラインのステータス（Passed/Failed/Runningなど）やトリガーとなったコミット、実行ステージなどが表示されます。クリックすると詳細な実行ログを確認できます。

Runnerについて

GitLab CI/CDのジョブを実行するのは「Runner」と呼ばれるエージェントです。RunnerはGitLabサーバーからジョブを受け取り、設定された環境でスクリプトを実行します。

GitLab.comを利用している場合は、Shared Runnerが用意されており、すぐにCI/CDを利用開始できます。独自の環境でジョブを実行したい場合や、特定のソフトウェアが必要な場合は、自分でSpecific Runnerをセットアップすることも可能です。

CI/CDは最初は難しく感じるかもしれませんが、小さな自動化から始めて徐々に複雑なパイプラインを構築していくことができます。コードの品質向上、デプロイの効率化、チームの生産性向上に不可欠な機能です。

その他のGitLab機能 (簡単に紹介)

GitLabは非常に多機能なプラットフォームです。これまでに紹介した機能以外にも、開発プロセスを支援する様々な機能が提供されています。

  • Container Registry: プロジェクトに関連するDockerイメージをビルドして保存・管理するための機能です。CI/CDパイプラインと連携して、コード変更時に自動的にDockerイメージをビルドし、Registryにプッシュするといった使い方が一般的です。
  • Package Registry: Maven, npm, NuGetなどの様々なパッケージを保存・管理するための機能です。CI/CDでビルドした成果物をパッケージとしてRegistryに公開し、他のプロジェクトで利用するといった使い方ができます。
  • Pages: 静的なWebサイトをプロジェクトのリポジトリから直接ホスティングするサービスです。ドキュメントサイトやブログなどを簡単に公開できます。通常はGitLab CI/CDを使ってサイトをビルドし、公開します。
  • Monitoring: アプリケーションのパフォーマンスやサーバーのリソースを監視するための機能です。Prometheusなどと連携できます。
  • Security: コードの脆弱性スキャン (SAST: Static Application Security Testing)、依存関係スキャン、コンテナスキャンなど、様々なセキュリティ機能がCI/CDパイプラインに組み込まれています。
  • Environments: デプロイ先の環境（Staging, Productionなど）を管理し、各環境にどのバージョンのアプリケーションがデプロイされているかを確認できます。

これらの機能は、プロジェクトの成熟度に合わせて段階的に活用していくことができます。

よくあるトラブルと対処法

GitやGitLabを使っていると、いくつかの一般的な問題に遭遇することがあります。

認証エラー (Permission denied)

git push や git clone の際に Permission denied (publickey). やパスワード入力が繰り返し求められるなどの認証エラーが発生することがあります。

  • SSHキー認証の場合:
    • ローカルで正しい秘密鍵が使われているか確認します（デフォルト以外の場所を使っている場合はGitに設定が必要です）。
    • GitLabに登録した公開鍵が、ローカルの秘密鍵とペアになっているものか確認します。
    • GitLabに公開鍵が正しく登録されているか確認します。
    • SSHエージェントが起動していて、秘密鍵が登録されているか確認します（特にパスフレーズを設定している場合）。
    • ssh -T [email protected] コマンドでGitLabへのSSH接続テストを行います。成功すれば Welcome to GitLab, @username! のようなメッセージが表示されます。
  • HTTPS認証の場合:
    • ユーザー名とパスワードを正しく入力しているか確認します。
    • 二要素認証を設定している場合は、パスワードの代わりにパーソナルアクセストークンを使用する必要がある場合があります。GitLabのSettings > Access Tokens で生成できます。

コンフリクト

前述の「コンフリクトの解消」セクションを参照してください。落ち着いて、Gitが示すマーカーを見ながら手動でファイルを修正し、git add してから git commit でマージを完了させます。

プッシュ/プルができない (リモートとの状態不一致)

  • git push 時に rejected と表示される場合：他の誰かがあなたより先にリモートにプッシュしており、リモートの履歴があなたのローカルより進んでいる状態です。先に git pull して最新の変更を取り込み、必要であればコンフリクトを解消してから再度プッシュしてください。
  • git pull 時にエラーになる場合：ローカルにコミットしていない変更がある状態でプルしようとすると問題が発生することがあります。先にローカルの変更をコミットまたはスタッシュ (git stash) してからプルするとスムーズです。

これらのトラブルは、Gitの基本的な仕組みやGitLabのリモートとの連携方法を理解することで、ほとんどが解決できます。エラーメッセージをよく読み、何が原因かを特定することが重要です。

まとめ：GitLab活用のステップアップ

本記事では、Gitの基本概念から始まり、GitLabでのプロジェクト管理、チーム開発に不可欠なマージリクエストや課題管理、そしてGitLabの強力なCI/CD機能の入門までを解説しました。

GitLabは非常に多機能なプラットフォームですが、一度にすべてを使いこなす必要はありません。まずは以下のステップでGitLabの活用を始めてみましょう。

  1. 個人のプロジェクトでGitLabを使ってみる: まずは一人でプロジェクトを作成し、コードのバージョン管理（コミット、ブランチ作成、リモートへのプッシュ/プル）に慣れましょう。
  2. チームでコード共有・レビューを始める: マージリクエストを使ったコードレビューのワークフローを取り入れてみましょう。これにより、コードの品質向上や知識共有が進みます。
  3. 課題管理を導入する: Issue機能を使って、タスクやバグをGitLab上で管理し、開発の進捗を見える化しましょう。MRとIssueを連携させるとより効率的です。
  4. CI/CDを試してみる: 簡単なテストやビルドの自動化から始めてみましょう。.gitlab-ci.yml をリポジトリに追加するだけで始められます。

GitLabはソフトウェア開発の様々な段階をサポートするツールです。これらの機能を段階的に導入していくことで、チームの開発プロセスを効率化し、より良いソフトウェアをより迅速に提供できるようになるはずです。

学習リソース

GitLabについてさらに深く学びたい場合は、以下のリソースが役立ちます。

  • GitLab公式ドキュメント: GitLabのすべての機能に関する詳細な情報が網羅されています。https://docs.gitlab.com/
  • Git公式ドキュメント: Git自体のコマンドや概念に関するリファレンスです。https://git-scm.com/doc
  • GitLab Learn: GitLabの様々な機能について学ぶためのチュートリアルやコースが提供されています。https://about.gitlab.com/learn/

GitLabを使いこなし、あなたの開発をさらに加速させてください！

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール