Zenn
🥷

Git履歴から機密情報を安全に分離する実践的手法

に公開
AI
Git
GitHub
Cursor
tech

Git履歴から機密情報を安全に分離する実践的手法 – ヘッダー画像

TL;DR

公開リポジトリに機密情報をコミットしてしまった場合の対処法として、git filter-repo + submodule を使った履歴完全削除と安全な分離管理手法を解説します。

背景：よくある開発現場の悩み

個人開発やスタートアップでこんな経験はありませんか？

  • 技術評価のためにリポジトリを公開したいが、機密情報も含んでいる
  • AI支援開発の設定ファイルや内部ドキュメントが外部に見えるのは困る
  • 業務委託の技術力評価でGitHubを見せる必要があるが、ノウハウは守りたい
  • 過去のコミット履歴に機密情報が残っているため、単純な削除では解決しない

今回は、このようなケースでGit履歴から機密情報を完全に削除し、submoduleで安全に管理する実践的手法を紹介します。

解決策の概要

📋 アプローチ

4 つのアプローチ図

  1. Git履歴からの完全削除: git filter-repo で過去の全履歴から機密情報を除去
  2. 安全な復元: バックアップから機密ファイルを復元
  3. プライベート管理: 別のプライベートリポジトリで機密情報を管理
  4. submodule統合: 開発時は透過的にアクセス、公開時は見えない状態を実現

🎯 達成される状態

  • 公開リポジトリ: 技術評価に最適な、クリーンなコードベース
  • 開発環境: 機密情報にアクセスしながら効率的な開発継続
  • セキュリティ: 過去の履歴から機密情報が完全に除去
  • 利便性: submoduleによる透過的なファイルアクセス

技術詳細

前提条件

  • Git 2.22.0以上（git filter-repo 対応）
  • 機密情報が含まれるパブリックリポジトリ
  • プライベートリポジトリ作成権限

Phase 1: 準備と安全確保

1. git filter-repo のインストール

# Homebrew（macOS/Linux）
brew install git-filter-repo

# pip（Python環境）
pip3 install git-filter-repo

# Ubuntu/Debian
sudo apt-get install git-filter-repo

2. 完全バックアップの作成

# リポジトリ全体をバックアップ
git clone . ../project-backup

# バックアップ確認
cd ../project-backup
git log --oneline | head -5  # 履歴の存在確認
ls sensitive-dir/            # 機密ファイル確認
cd ../original-project

⚠️ 重要: この段階での完全バックアップが、後の復元における最後の砦になります。

Phase 2: Git履歴からの完全除去

git filter-repo 前後でコミット履歴

1. 機密ディレクトリの履歴削除

# 特定ディレクトリを全履歴から削除
git filter-repo --path sensitive-docs/ --invert-paths
git filter-repo --path .secrets/ --invert-paths
git filter-repo --path internal-configs/ --invert-paths

# 個別ファイルの削除も可能
git filter-repo --path api-keys.json --invert-paths

2. リモートリポジトリへの強制適用

# 履歴書き換えをリモートに反映
git push --force-with-lease

# 結果確認
# - GitHub上で過去のコミットを確認
# - 機密ファイルが全履歴から消えていることを確認

Phase 3: 機密情報の安全な復元管理

1. プライベートリポジトリの作成

# GitHub CLI を使用した場合
gh repo create project-secrets --private

# または GitHub Web UI で作成
# Repository name: project-secrets
# Visibility: Private

2. 機密ファイルの復元とアップロード

# バックアップから機密ファイルを復元
mkdir project-secrets-local
cd project-secrets-local

# 必要なファイル・ディレクトリをコピー
cp -r ../project-backup/sensitive-docs/ ./
cp -r ../project-backup/.secrets/ ./
cp -r ../project-backup/internal-configs/ ./

# プライベートリポジトリにプッシュ
git init
git add .
git commit -m "Initial commit: sensitive project configurations"
git branch -M main
git remote add origin https://github.com/username/project-secrets.git
git push -u origin main

# ローカル作業ディレクトリを削除
cd .. && rm -rf project-secrets-local

Phase 4: submodule による統合

公開リポジトリと submodule の関係図

1. メインプロジェクトへのsubmodule追加

# プライベートリポジトリをsubmoduleとして追加
git submodule add https://github.com/username/project-secrets.git secrets

# submodule確認
git submodule status
ls secrets/  # 機密ファイルが見えることを確認

2. 開発ツール設定の更新

# 設定ファイルのパス更新例

# Before
config_path = ".secrets/api-config.json"

# After
config_path = "secrets/.secrets/api-config.json"

# IDE設定なども適切に更新

3. .gitignore の設定（オプション）

# submodule自体を公開リポジトリから隠したい場合
echo "secrets/" >> .gitignore

実際の効果と検証

🔍 セキュリティ検証

セキュリティ検証チェックリスト

# 過去のコミットチェック
git log --follow sensitive-docs/  # → エラーまたは結果なし

# 特定コミットでの確認
git show abc1234:sensitive-docs/secret.json  # → ファイルが存在しない

# GitHub上での検索
# リポジトリ内検索で機密キーワードがヒットしないことを確認

📊 利便性検証

# 開発時のファイルアクセス
cat secrets/sensitive-docs/config.yaml     # ✅ 正常アクセス可能
./scripts/deploy.sh secrets/.secrets/      # ✅ スクリプトも正常動作

# 新規クローン時（他の開発者）
git clone https://github.com/username/project-public.git
ls secrets/  # → 空ディレクトリ（プライベートリポジトリにアクセス権なし）

応用例とユースケース

🎯 個人開発者

  • ポートフォリオ公開: 技術力アピールと機密保護の両立
  • 業務委託応募: GitHubベースの技術評価対応
  • オープンソース化: 内部ツールの公開版作成

🏢 スタートアップ・小規模チーム

  • 投資家向けデモ: コードベース公開と企業秘密保護
  • 採用活動: 技術レベル公開と競合優位性維持
  • 外部委託: 必要な範囲のみの情報開示

🔬 研究・教育機関

  • 論文公開: 再現可能な研究コードと機密データの分離
  • 教材作成: 実践的コード例と個人情報保護

注意点とベストプラクティス

⚠️ 作業前の確認事項

  1. フォーク状況の確認: 他者によるフォークがないか確認
  2. チーム合意: 履歴書き換えの影響をチーム内で共有
  3. バックアップ戦略: 複数のバックアップ手段を準備

🛡️ セキュリティ考慮事項

# 作業履歴の確認
git reflog  # ローカルの作業履歴をチェック

# ガベージコレクション実行
git gc --prune=all --aggressive  # 削除された履歴を完全に除去

🔄 継続的な運用

# submodule更新の自動化
git submodule update --remote secrets

# 定期的な同期スクリプト
#!/bin/bash
cd secrets
git pull origin main
cd ..
git add secrets
git commit -m "Update secrets submodule"

まとめ

解決策の概要再掲

この手法により、以下を同時に実現できます：

✅ 達成される価値

  • 技術評価機会の最大活用: クリーンなリポジトリで技術力をアピール
  • 機密情報の確実な保護: 過去の履歴から完全に除去
  • 開発効率の維持: submoduleによる透過的アクセス
  • 運用の簡便性: 日常的な開発フローへの影響最小化

🎯 適用推奨ケース

  • 個人開発プロジェクトの公開前整理
  • 業務委託・転職活動でのポートフォリオ準備
  • 内部ツールのオープンソース化
  • 研究コードの論文公開準備

この手法は、現代の開発において「オープン化の価値」と「機密情報の保護」を両立させる実践的なソリューションとして活用できます。

参考リンク

この記事が、セキュアな開発環境の構築に役立てば幸いです。

Discussion