【GitLab × Git LFS】既存のGitLab環境でデザインアセット用リポジトリを切り出して容量激減＆スマートに管理する方法 / グループ化と Git LFS

SwiftUI

「アプリのリポジトリが重くて git clone に時間がかかる…」
「PSDや高解像度PNGをコミットしたら、リポジトリの容量が数GBに跳ね上がった…」

開発現場でよくあるこの問題。原因の多くは「デザインファイルや本番アセットなどの大容量バイナリファイルを、アプリ本体のソースコードと同じリポジトリで管理していること」にあります。

この記事では、すでに導入済みのGitLab環境を活用し、デザイン専用リポジトリの切り出しと Git LFS（Large File Storage） を組み合わせて、リポジトリを大幅に軽量化しながらスマートに管理する実践的な手順を解説します。

  1. 1. はじめに：なぜデザインファイルを本体から分けるべきなのか？
    1. 解決策：リポジトリの分離 ＋ Git LFS
  2. 2. GitLabへのデザイン専用プロジェクトの追加
    1. 手順：グループ内に別プロジェクトとして作成する
  3. 既存プロジェクトのグループ化
    1. 1. GitLabのWeb画面で対象プロジェクトを開く
    2. 2. 「Advanced（詳細設定）」を開く
    3. 3. 「Transfer project（プロジェクトの転送）」を実行する
  4. 移動時の注意点（ローカル環境の更新）
  5. 3. ローカル環境でのGit LFSセットアップ
    1. Step 1: Git LFSのインストール（初回のみ）
    2. Step 2: 追跡対象のファイル形式を指定する
    3. Step 3: .gitattributes をコミットしてプッシュ
  6. 4. アプリ本体プロジェクトとの連携（紐付け）
    1. 方法A：Git Submodule でバージョンを固定する（推奨）
    2. 方法B：GitLab CI/CD でビルド時に自動取得する
  7. 5. まとめ：手動バックアップからの脱却
  8. 1. はじめに：なぜデザインファイルを本体から分けるべきなのか？
    1. 解決策：リポジトリの分離 ＋ Git LFS
  9. 2. GitLabへのデザイン専用プロジェクトの追加
    1. 手順：グループ内に別プロジェクトとして作成する
  10. 3. ローカル環境でのGit LFSセットアップ
    1. Step 1: Git LFSのインストール（初回のみ）
    2. Step 2: 追跡対象のファイル形式を指定する
    3. Step 3: .gitattributes をコミットしてプッシュ
  11. 4. アプリ本体プロジェクトとの連携（紐付け）
    1. 方法A：Git Submodule でバージョンを固定する（推奨）
    2. 方法B：GitLab CI/CD でビルド時に自動取得する
  12. 5. まとめ：手動バックアップからの脱却

1. はじめに：なぜデザインファイルを本体から分けるべきなのか？

アプリやWebサイト開発において、ソースコード（テキスト）とデザイン原稿（バイナリ）を同じリポジトリで管理し続けると、次のような課題が発生します。

  • git clone や git pull が激重になる
    Gitは過去の全履歴をローカルに保持する仕組みのため、更新を重ねた大容量ファイルがすべてダウンロードされ、エンジニアの作業効率が著しく低下します。
  • 手動バックアップの形骸化
    「〇〇v2_final確定.psd」のような手動保存や、クラウドストレージへの手動アップロードは、ヒューマンエラーやバージョン先祖返りの原因になります。

解決策：リポジトリの分離 ＋ Git LFS

  1. リポジトリの分離: アプリ本体とデザインアセットでリポジトリを分け、コード側の軽量化を図る。
  2. Git LFSの導入: デザインリポジトリ側でGit LFSを使い、バイナリファイルの実体と履歴リンク（ポインタ）を分離して保存する。

この構成を作ることで、無駄なストレージ消費を抑えつつ、いつでも過去の任意のコミット（スナップショット）に復元できる強固な管理環境が完成します。

2. GitLabへのデザイン専用プロジェクトの追加

GitLabは、GitHub等と比べてもGit LFSとの親和性が非常に高く、標準で強力なサポートが用意されています。

手順：グループ内に別プロジェクトとして作成する

既存のGitLab環境で「グループ（Group）」運用をしている場合は、アプリ本体と同じグループ内に新規プロジェクト（例: app-design-assets）を追加するのが最もスムーズです。

💡 GitLabで運用するメリット

  • 設定不要でLFSが有効: 新規プロジェクト作成時点でGit LFS機能がデフォルトでONになっています。
  • 権限管理の一元化: グループ単位でアクセス権を設定していれば、デザイナーやエンジニアへの権限付与も一括で行えます。
  • Web画面での高機能表示: GitLabのWeb UI上でLFS管理下の画像プレビューやバッジ表示（LFS タグ）が標準対応しています。

既存プロジェクトのグループ化

※設定を変更するには、対象プロジェクトの「Owner（所有者）」権限が必要です。

  • グループ > 新規グループ でグループを作った状態から

1. GitLabのWeb画面で対象プロジェクトを開く

  1. 移動させたい既存プロジェクトのページを開きます。
  2. 左側のサイドメニューの一番下にある 「Settings（設定）」 ＞ 「General（一般）」 をクリックします。

2. 「Advanced（詳細設定）」を開く

  1. ページ最下部にある 「Advanced」 セクションの 「Expand（展開）」 ボタンをクリックします。

3. 「Transfer project（プロジェクトの転送）」を実行する

  1. 「Transfer project」 という項目を探します。
  2. ドロップダウンメニューから、移動先（所属させたい）グループ名を選択します。
  3. 「Transfer project」 ボタンをクリックします。
  4. 確認のポップアップが出たら、プロジェクト名を入力して実行を確定します。
これで、プロジェクトがグループの傘下に移動し、
https://gitlab.example.com/your-name/my-project
gitlab.example.com
(https://gitlab.example.com/your-name/my-project) から
https://gitlab.example.com/your-group/my-project
gitlab.example.com
(https://gitlab.example.com/your-group/my-project) へ自動的に再配置されます。

移動時の注意点（ローカル環境の更新）

プロジェクトのURL（リポジトリURL）が変わるため、すでにローカルに git clone しているメンバーは、ローカル側の接続先URL（git remote）を更新する必要があります。Bash

# 移動後の新しいURLに変更する
git remote set-url origin https://gitlab.example.com/your-group/my-project.git

# 確認（URLが更新されていればOK）
git remote -v

💡 リダイレクト機能について

GitLabには旧URLからの自動リダイレクト機能があるため、直ちにエラーになることは稀ですが、チーム運用ではローカルの remote url も新しいグループのURLに更新しておくのが安全です。

後から構成を変更したくなった場合でも柔軟に整理整頓できるので、安心してお試しください！

3. ローカル環境でのGit LFSセットアップ

デザイン専用リポジトリを作成したら、ローカル環境でGit LFSの追跡設定を行います。一度設定してしまえば、普段の git add や git commit などの操作感を変更する必要はありません。

Step 1: Git LFSのインストール（初回のみ）

お使いの環境に合わせてGit LFSをインストールします。

# macOS (Homebrew) の場合
brew install git-lfs

# Windows (Git for Windows をお使いの場合は標準で同梱されています)
git lfs install

Step 2: 追跡対象のファイル形式を指定する

作成したデザインリポジトリのルートディレクトリで、LFSで管理したい拡張子を指定します。

# デザインリポジトリへ移動
cd app-design-assets

# PSDやAIファイルをLFS追跡対象に設定
git lfs track "*.psd"
git lfs track "*.ai"
git lfs track "*.png"

このコマンドを実行すると、リポジトリ直下に .gitattributes という設定ファイルが自動生成（または更新）されます。

Step 3: .gitattributes をコミットしてプッシュ

.gitattributes には「どのファイルをLFSで管理するか」のルールが書かれています。これをリポジトリにコミットすることで、チーム全員に同じルールが適用されます。

git add .gitattributes
git commit -m "chore: Git LFSの追跡ルールを追加"
git push origin main

これで準備完了です！以降は .psd や .png を追加・変更して git push するたびに、裏側で実体データがLFSストレージへ送られ、Gitリポジトリ側には数バイトの「スナップショット参照リンク（ポインタ）」だけが記録されます。

4. アプリ本体プロジェクトとの連携（紐付け）

「リポジトリを分けたのは良いけれど、アプリ本体とデザインアセットのバージョン同期はどうするのか？」という疑問が生じます。これにはいくつかのスマートな連携方法があります。

方法A：Git Submodule でバージョンを固定する（推奨）

アプリ本体のリポジトリ内に、デザインリポジトリをサブモジュールとして読み込む方法です。

# アプリ本体のリポジトリ内で実行
git submodule add https://gitlab.example.com/your-group/app-design-assets.git Assets/Design
  • メリット: アプリ本体のコミットに対して、「デザインリポジトリのどのコミット（スナップショット）を使っているか」が正確に紐付きます。デザイン側が更新されても、アプリ側でSubmoduleの更新コミットを打たない限り、勝手にアセットが差し変わる心配がありません。

方法B：GitLab CI/CD でビルド時に自動取得する

アプリリポジトリ内にはデザインファイルを一切置かず、アプリをビルド（リリース）するパイプライン処理の段階で、GitLab CI/CDを使って最新のアセットを引き込む構成です。

  • メリット: アプリリポジトリ自体を完全に軽量な状態に保てます。

5. まとめ：手動バックアップからの脱却

今回紹介した「GitLab × Git LFS × リポジトリ分離」の構成を導入することで、以下のような理想的な開発環境が手に入ります。

  • 容量の劇的な削減: Gitリポジトリ内には軽量なリンク情報のみが残り、git clone が一瞬で完了する。
  • 厳格なバージョン管理: コミットのタイミングで「ファイル実体のスナップショット」と「参照リンク」が全自動で保持されるため、手動のタグ付けやフォルダ複製が不要になる。
  • 開発とデザインの健全な分離: エンジニアはアプリコードに集中でき、デザイナーは安心して大容量アセットを確定版としてバージョン管理できる。

既存のGitLab環境があれば、追加費用をかけずに今すぐ導入できる構成です。リポジトリの肥大化やアセット管理に悩んでいる方は、ぜひ試してみてください！

ご提示いただいたタイトルと目次構成に基づき、そのままブログやQiita / Zenn、社内技術Wikiなどに投稿できる形式で記事を作成しました！

【GitLab × Git LFS】既存のGitLab環境でデザインアセット用リポジトリを切り出して容量激減＆スマートに管理する方法

「アプリのリポジトリが重くて git clone に時間がかかる…」
「PSDや高解像度PNGをコミットしたら、リポジトリの容量が数GBに跳ね上がった…」

開発現場でよくあるこの問題。原因の多くは「デザインファイルや本番アセットなどの大容量バイナリファイルを、アプリ本体のソースコードと同じリポジトリで管理していること」にあります。

この記事では、すでに導入済みのGitLab環境を活用し、デザイン専用リポジトリの切り出しと Git LFS（Large File Storage） を組み合わせて、リポジトリを大幅に軽量化しながらスマートに管理する実践的な手順を解説します。

1. はじめに：なぜデザインファイルを本体から分けるべきなのか？

アプリやWebサイト開発において、ソースコード（テキスト）とデザイン原稿（バイナリ）を同じリポジトリで管理し続けると、次のような課題が発生します。

  • git clone や git pull が激重になる
    Gitは過去の全履歴をローカルに保持する仕組みのため、更新を重ねた大容量ファイルがすべてダウンロードされ、エンジニアの作業効率が著しく低下します。
  • 手動バックアップの形骸化
    「〇〇v2_final確定.psd」のような手動保存や、クラウドストレージへの手動アップロードは、ヒューマンエラーやバージョン先祖返りの原因になります。

解決策：リポジトリの分離 ＋ Git LFS

  1. リポジトリの分離: アプリ本体とデザインアセットでリポジトリを分け、コード側の軽量化を図る。
  2. Git LFSの導入: デザインリポジトリ側でGit LFSを使い、バイナリファイルの実体と履歴リンク（ポインタ）を分離して保存する。

この構成を作ることで、無駄なストレージ消費を抑えつつ、いつでも過去の任意のコミット（スナップショット）に復元できる強固な管理環境が完成します。

2. GitLabへのデザイン専用プロジェクトの追加

GitLabは、GitHub等と比べてもGit LFSとの親和性が非常に高く、標準で強力なサポートが用意されています。

手順：グループ内に別プロジェクトとして作成する

既存のGitLab環境で「グループ（Group）」運用をしている場合は、アプリ本体と同じグループ内に新規プロジェクト（例: app-design-assets）を追加するのが最もスムーズです。

💡 GitLabで運用するメリット

  • 設定不要でLFSが有効: 新規プロジェクト作成時点でGit LFS機能がデフォルトでONになっています。
  • 権限管理の一元化: グループ単位でアクセス権を設定していれば、デザイナーやエンジニアへの権限付与も一括で行えます。
  • Web画面での高機能表示: GitLabのWeb UI上でLFS管理下の画像プレビューやバッジ表示（LFS タグ）が標準対応しています。

3. ローカル環境でのGit LFSセットアップ

デザイン専用リポジトリを作成したら、ローカル環境でGit LFSの追跡設定を行います。一度設定してしまえば、普段の git add や git commit などの操作感を変更する必要はありません。

Step 1: Git LFSのインストール（初回のみ）

お使いの環境に合わせてGit LFSをインストールします。

# macOS (Homebrew) の場合
brew install git-lfs

# Windows (Git for Windows をお使いの場合は標準で同梱されています)
git lfs install

Step 2: 追跡対象のファイル形式を指定する

作成したデザインリポジトリのルートディレクトリで、LFSで管理したい拡張子を指定します。

# デザインリポジトリへ移動
cd app-design-assets

# PSDやAIファイルをLFS追跡対象に設定
git lfs track "*.psd"
git lfs track "*.ai"
git lfs track "*.png"

このコマンドを実行すると、リポジトリ直下に .gitattributes という設定ファイルが自動生成（または更新）されます。

Step 3: .gitattributes をコミットしてプッシュ

.gitattributes には「どのファイルをLFSで管理するか」のルールが書かれています。これをリポジトリにコミットすることで、チーム全員に同じルールが適用されます。

git add .gitattributes
git commit -m "chore: Git LFSの追跡ルールを追加"
git push origin main

これで準備完了です！以降は .psd や .png を追加・変更して git push するたびに、裏側で実体データがLFSストレージへ送られ、Gitリポジトリ側には数バイトの「スナップショット参照リンク（ポインタ）」だけが記録されます。

4. アプリ本体プロジェクトとの連携（紐付け）

「リポジトリを分けたのは良いけれど、アプリ本体とデザインアセットのバージョン同期はどうするのか？」という疑問が生じます。これにはいくつかのスマートな連携方法があります。

方法A：Git Submodule でバージョンを固定する（推奨）

アプリ本体のリポジトリ内に、デザインリポジトリをサブモジュールとして読み込む方法です。

# アプリ本体のリポジトリ内で実行
git submodule add https://gitlab.example.com/your-group/app-design-assets.git Assets/Design
  • メリット: アプリ本体のコミットに対して、「デザインリポジトリのどのコミット（スナップショット）を使っているか」が正確に紐付きます。デザイン側が更新されても、アプリ側でSubmoduleの更新コミットを打たない限り、勝手にアセットが差し変わる心配がありません。

方法B：GitLab CI/CD でビルド時に自動取得する

アプリリポジトリ内にはデザインファイルを一切置かず、アプリをビルド（リリース）するパイプライン処理の段階で、GitLab CI/CDを使って最新のアセットを引き込む構成です。

  • メリット: アプリリポジトリ自体を完全に軽量な状態に保てます。

5. まとめ：手動バックアップからの脱却

今回紹介した「GitLab × Git LFS × リポジトリ分離」の構成を導入することで、以下のような理想的な開発環境が手に入ります。

  • 容量の劇的な削減: Gitリポジトリ内には軽量なリンク情報のみが残り、git clone が一瞬で完了する。
  • 厳格なバージョン管理: コミットのタイミングで「ファイル実体のスナップショット」と「参照リンク」が全自動で保持されるため、手動のタグ付けやフォルダ複製が不要になる。
  • 開発とデザインの健全な分離: エンジニアはアプリコードに集中でき、デザイナーは安心して大容量アセットを確定版としてバージョン管理できる。

既存のGitLab環境があれば、追加費用をかけずに今すぐ導入できる構成です。リポジトリの肥大化やアセット管理に悩んでいる方は、ぜひ試してみてください！

お気軽にコメントください！

スパム対応のためコメント認証に数日かかることがありますが、お気軽にコメントいただけると嬉しいです^^

コメント

タイトルとURLをコピーしました