Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】How to Remove Sensitive or Large Files From Your Git Repository

2025年09月18日に「Dev.to」が公開したITニュース「How to Remove Sensitive or Large Files From Your Git Repository」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

Gitリポジトリに機密ファイル(.env)や大容量ファイル(node_modules)を誤ってプッシュした場合の対処法を解説。まず.gitignoreで今後追跡しない設定をし、`git rm --cached`でリモートから削除する。さらに履歴からも完全に消すツールも紹介。初回コミット前に.gitignoreを設定することが重要だ。

ITニュース解説

ソフトウェア開発において、Gitはバージョン管理に不可欠なツールだが、その使い方を誤ると予期せぬ問題を引き起こすことがある。特に、システムエンジニアを目指す初心者が陥りやすいミスとして、機密情報を含むファイルや非常に大きなファイルを、誤ってGitリポジトリ、特にGitHubなどの公開されたリモートリポジトリにプッシュしてしまう事例が挙げられる。

この問題は、Gitの基本的な動作に起因する。git initコマンドで新しいリポジトリを初期化すると、Gitはプロジェクト内の全てのファイルをデフォルトで追跡対象とする。もし、この段階で特定のファイルを無視するための設定を行わずに最初のコミットをしてしまうと、意図せず機密ファイルや巨大なファイルがリモートリポジトリにアップロードされてしまうのだ。

具体的にどのようなファイルが問題となるかというと、まず機密ファイルとしては、.envファイルが代表的だ。このファイルには、データベースへの接続情報やAPIキーなど、プロジェクトのセキュリティ上非常に重要な情報が含まれていることが多い。もしこのようなファイルが公開されたリポジトリにプッシュされてしまうと、悪意のある第三者に情報が漏洩し、不正利用される危険性がある。次に、大きなファイルやフォルダとしては、Node.jsプロジェクトにおけるnode_modulesフォルダが代表的である。このフォルダには、プロジェクトが依存する大量のライブラリやモジュールが含まれており、非常に容量が大きい。これをGitリポジトリに含めてしまうと、リポジトリ全体のサイズが膨大になり、他の開発者がリポジトリをクローンする際に時間がかかったり、ディスク容量を圧迫したりする原因となる。

このような問題を未然に防ぎ、あるいは既に発生してしまった場合に対処するための最も基本的な方法が、.gitignoreファイルを利用することである。.gitignoreファイルは、Gitに「これらのファイルやフォルダは追跡しないでほしい」と指示するための設定ファイルで、プロジェクトのルートディレクトリに配置する。例えば、touch .gitignoreコマンドでファイルを作成し、その中にnode_modules/.env*.logといった形で、追跡を避けたいファイル名やフォルダ名を記述する。これにより、Gitは将来のコミットでこれらのファイルを無視するようになる。

しかし、もし既にこれらのファイルをコミットしてしまっている場合は、.gitignoreに追記するだけでは不十分だ。なぜなら、.gitignoreはあくまで「今後」の追跡を止める指示であり、既にGitの管理下に置かれているファイルには影響しないからである。この場合、まずはGitの管理対象からこれらのファイルを削除する必要がある。これにはgit rm -r --cached <ファイル名>というコマンドを用いる。例えば、git rm -r --cached node_modulesと実行すると、node_modulesフォルダはGitのインデックス(追跡対象のリスト)から削除されるが、実際にローカルのディスク上にあるファイル自体は削除されず、そのまま残る。これは非常に重要なポイントで、必要なファイルを手元に残しつつ、Gitリポジトリからは切り離せることを意味する。.envファイルについても同様にgit rm --cached .envと実行する。これらの変更をgit commit -m "Remove node_modules and .env from repository"といったコミットメッセージと共にコミットし、その後git push origin mainなどでリモートリポジトリにプッシュすることで、リモートからもこれらのファイルが削除される。

さらに、もし機密性の高い情報、例えばパスワードやAPIキーなどを過去のコミット履歴の中にプッシュしてしまっていた場合、ただファイルを削除してプッシュするだけでは不十分なケースがある。Gitの履歴は過去の変更を全て記録しているため、一見削除されたように見えても、過去のコミットをたどればその機密情報にアクセスできてしまう可能性があるからだ。このような状況では、リポジトリの履歴自体を書き換えるという、より強力な手段が必要となる。これは通常、最終手段として用いられるもので、特に共有リポジトリで行う場合は他の開発者との調整が必須となるほど影響が大きい操作だ。

履歴を書き換えるツールとしては、「BFG Repo Cleaner」や「git filter-repo」が有名である。BFG Repo Cleanerを使う場合は、brew install bfgなどでツールをインストール後、問題のリポジトリをミラークローンし、bfg --delete-files .envのようにコマンドを実行することで、リポジトリの全履歴から指定したファイルを削除できる。その後、古い参照を整理し、git push --forceでリモートリポジトリに強制的にプッシュすることで、履歴の書き換えが完了する。git filter-repoも同様に、pip install git-filter-repoでインストールし、git filter-repo --path .env --invert-pathsのように実行することで特定のファイルを履歴から削除する。これらのツールは強力であるため、使用前には必ずリポジトリのバックアップを取るなど、細心の注意を払うことが重要だ。

このような問題を未然に防ぐための最善策は、開発の初期段階、つまり最初のコミットを行う前に必ず.gitignoreファイルを作成し、必要な除外設定を記述しておくことである。また、機密情報は.envファイルに保存し、プログラムからは環境変数として読み込むように徹底することも重要だ。これにより、ソースコード内に機密情報が直接記述されるのを防げる。さらに、継続的インテグレーション/継続的デリバリー(CI/CD)パイプラインを利用している場合は、GitHub Secretsのような安全な方法で機密情報を管理することも検討すべきだ。そして何よりも、コミットを行う前には必ずgit statusコマンドを実行し、どのファイルがプッシュされようとしているのかを確認する習慣をつけることが、多くのミスを防ぐ上で最も効果的なベストプラクティスとなるだろう。これらの習慣を身につけることで、より安全で効率的なソフトウェア開発が可能となる。

関連コンテンツ

関連IT用語