0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

GitLabリポジトリのクローン：基本から最適化まで

0
Posted at

(トップページはこちら)

GitLabリポジトリのクローン：基本から最適化まで

GitLabからリポジトリをクローンする方法は、シンプルなgit cloneだけではありません。認証方式の選択、IDE統合、そして大規模リポジトリに対応する部分クローンまで、状況に応じた最適な手法があります。本記事では、GitLab.comを前提に、実務で役立つクローン技術を解説します。

目次

  1. 認証方式の選択：SSHとHTTPS
  2. IDE統合：開発環境への直接クローン
  3. 部分クローン：大規模リポジトリの最適化

1. 認証方式の選択：SSHとHTTPS

1.1 SSH接続（推奨）

SSHは一度認証を設定すれば、以降の操作で認証が不要になります。日常的な開発作業に最適です。

クローン手順：

  1. SSHキーをGitLab.comに登録（初回のみ）
  2. プロジェクトページ右上の「Code」→「Clone with SSH」のURLをコピー
  3. ターミナルで以下を実行
git clone git@gitlab.com:ユーザー名/プロジェクト名.git
cd プロジェクト名

1.2 HTTPS接続

HTTPSは操作ごとに認証が必要ですが、OAuth認証ヘルパーを使用することで、認証の手間を軽減できます。

クローン手順：

  1. プロジェクトページ右上の「Code」→「Clone with HTTPS」のURLをコピー
  2. ターミナルで以下を実行
git clone https://gitlab.com/ユーザー名/プロジェクト名.git
  1. ユーザー名とパスワードを入力

二要素認証（2FA）を有効にしている場合：

パスワードの代わりにアクセストークンを使用する必要があります。

  • 個人アクセストークン（read_repositoryまたはwrite_repository権限が必要）
  • プロジェクトアクセストークン
  • グループアクセストークン
  • デプロイトークン

1.3 トークンを使用したクローン

git clone https://gitlab.com/ユーザー名/プロジェクト名.git
Username: <ユーザー名>
Password: <トークン>

トークンの安全な管理方法については、以下の記事で詳しく解説しています。

2. IDE統合：開発環境への直接クローン

GitLabは主要なIDEとの統合により、ブラウザから直接開発環境にクローンできます。

2.1 対応IDE

  • Apple Xcode（macOS、.xcodeprojまたは.xcworkspaceを含むプロジェクト）
  • Visual Studio Code（GitLab Workflow拡張機能のインストールを推奨）
  • IntelliJ IDEA

2.2 使用方法

  1. プロジェクトページ右上の「Code」を選択
  2. 「Open in your IDE」から使用するIDEを選択
  3. SSHまたはHTTPSを選択
  4. クローン先のフォルダを指定

初回利用時は、ブラウザがカスタムプロトコル（vscode://、jetbrains://など）を処理するための許可を求める場合があります。「開く」または「リンクを開く」を選択してください。

3. 部分クローン：大規模リポジトリの最適化

ここからが本題です。リポジトリが巨大化すると、クローンに時間がかかり、ディスク容量も圧迫します。部分クローンを使えば、必要なデータだけを取得して、これらの問題を解決できます。

必要環境： Git 2.22.0以降

3.1 ユースケース別の最適化手法

3.1.1 ケース1：大きなバイナリファイルを含むリポジトリ

画像、動画、ビルド成果物など、大きなファイルを多数含むリポジトリの場合、ファイルサイズでフィルタリングします。

例：1MB以上のファイルを除外してクローン

git clone --filter=blob:limit=1m git@gitlab.com:ユーザー名/プロジェクト名.git

効果：

  • 初回クローンが高速化（大きなファイルをスキップ）
  • ディスク使用量が大幅に削減
  • 必要になった時点でオンデマンドにダウンロード

注意点：

  • チェックアウト時に必要なファイルは自動的にダウンロードされます
  • ブランチ切り替え時に追加のダウンロードが発生する場合があります

3.1.2 ケース2：モノレポで特定のディレクトリだけ必要な場合

複数のプロジェクトが1つのリポジトリに格納されているモノレポで、特定のプロジェクトだけを扱う場合に有効です。

例：全ファイルを除外してクローン後、必要なディレクトリだけチェックアウト

# 全ファイルを除外してクローン
git clone --filter=blob:none --sparse git@gitlab.com:ユーザー名/プロジェクト名.git
cd プロジェクト名

# 必要なディレクトリだけチェックアウト
git sparse-checkout set services/api services/shared-lib --cone

効果：

  • クローンが劇的に高速化（例：数GB→数十MB）
  • 作業ディレクトリに必要なファイルだけが存在
  • ビルド時間の短縮

実行結果の例：

$ git clone --filter=blob:none --sparse git@gitlab.com:gitlab-com/www-gitlab-com.git
Cloning into 'www-gitlab-com'...
remote: Enumerating objects: 678296, done.
remote: Counting objects: 100% (678296/678296), done.
Receiving objects: 100% (678296/678296), 81.06 MiB | 5.74 MiB/s, done.
Resolving deltas: 100% (472342/472342), done.
Updating files: 100% (28/28), done.

$ cd www-gitlab-com

$ git sparse-checkout set data --cone
remote: Enumerating objects: 301, done.
Receiving objects: 100% (301/301), 1.15 MiB | 608.00 KiB/s, done.
Updating files: 100% (302/302), done.

フルクローンと比較すると、初期ダウンロード量が数GB→81MBに削減されています。

3.1.3 ケース3：CI/CDで最小限のデータだけ取得したい場合

CIパイプラインでは、履歴全体は不要で、最新のコードだけあれば十分なケースが多くあります。

例：浅いクローン（履歴の深さを制限）と部分クローンの組み合わせ

git clone --filter=blob:none --depth=1 git@gitlab.com:ユーザー名/プロジェクト名.git

効果：

  • CI実行時間の短縮
  • ランナーのディスク使用量削減
  • 並列実行時のネットワーク負荷軽減

3.2 高度な技術：ファイルパスによるフィルタリング

特定のパスだけを含める、より細かい制御も可能です。ただし、この機能はまだ実験的で、パフォーマンスに課題があります。

警告： 現時点では、前述のオブジェクトタイプによるフィルタリング + sparse-checkoutの組み合わせの方が安定しています。

使用例：

  1. フィルタ仕様ファイルを作成（.gitfilterspec）
# 含めるパスを指定
api-service/.gitfilterspec
api-service/
shared-components/
  1. フィルタを適用してクローン
git clone --sparse --filter=sparse:oid=main:api-service/.gitfilterspec git@gitlab.com:ユーザー名/プロジェクト名.git

3.3 部分クローンの解除方法

部分クローンを通常のクローンに戻したい場合の手順です。

手順：

  1. sparse-checkoutを無効化（使用している場合）
git sparse-checkout disable
  1. 欠落しているオブジェクトを確認してフェッチ
# 欠落オブジェクトの数を確認
git rev-list --objects --all --missing=print | grep -e '^\?' | wc -l

# すべての欠落オブジェクトをフェッチ
git fetch origin $(git rev-list --objects --all --missing=print | grep -oP '^\?\K\w+')
  1. リポジトリを再パック
git repack -a -d
  1. .promisorファイルを削除

.git/objects/pack/ディレクトリ内のpack-<SHA1>.promisorファイル（通常は空）を削除します。

  1. 部分クローン設定を削除
git config --unset remote.origin.promisor
git config --unset remote.origin.partialclonefilter

3.4 実測：部分クローンの効果

実際のプロジェクトでの効果を見てみましょう。

通常のクローン：

ダウンロード量：2.34 GB
時間：約8分（環境による）
ディスク使用量：2.5 GB

部分クローン（1MBフィルタ）：

ダウンロード量：約600 MB
時間：約2分
ディスク使用量：700 MB
削減率：約72%

部分クローン + sparse-checkout：

ダウンロード量：約80 MB
時間：約30秒
ディスク使用量：100 MB
削減率：約96%

特に、帯域幅が限られた環境や、ストレージ容量が制約のある環境では、この差は決定的です。

4. まとめ：どの方法を選ぶべきか

4.1 選択フローチャート

リポジトリのサイズは？
  ├─ 小〜中規模（< 500MB）
  │   → 通常のクローンで十分
  │
  ├─ 大規模で大きなバイナリファイルが多い
  │   → ファイルサイズフィルタ（--filter=blob:limit=1m）
  │
  ├─ モノレポで特定のディレクトリだけ必要
  │   → オブジェクトフィルタ + sparse-checkout
  │
  └─ CI/CDで使用
      → 浅いクローン + 部分クローン（--depth=1 --filter=blob:none）

4.2 推奨アプローチ

  • 日常開発：SSH接続 + 必要に応じて部分クローン
  • 初めてのプロジェクト：まず通常クローンを試し、遅い場合は部分クローンを検討
  • 大規模リポジトリ：最初から部分クローン + sparse-checkoutを活用
  • CI/CD：常に最小限のデータだけ取得する設定を推奨

部分クローンは、ただの高速化技術ではありません。ネットワーク帯域、ストレージ、ビルド時間という、3つのボトルネックを同時に解決する実用的な手法です。

次にリポジトリをクローンする時、この記事を思い出して、最適な方法を選択してください。数分の設定で、日々の開発体験が大きく変わります。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?