秘密鍵をGitに入れてしまったとき

個人アプリ開発でいちばん焦る事故のひとつが、署名用の秘密鍵を Git に入れてしまうことです。

コッペの開発でも ios_distribution_private_key.pem を履歴に載せてしまったことがあり、プライベートリポジトリとはいえ、これがチーム開発で起きていたらゾッとする出来事です。

この記事は、本来コミットすべきではないもの（今回は鍵ファイル）を例に、何をするかを手順としてまとめます。コマンドの細部は環境で違うので、順番と判断を中心に書きます。

先に結論： まずは鍵を失効させること。履歴から消す作業は、そのあとです。一度でも外に出た鍵は、リポジトリがプライベートでも使い続けない方がよいです。

何が起きているか

Apple の配布用秘密鍵（例：ios_distribution_private_key.pem）がコミットに含まれると、次のリスクが同時に出ます。

つまり問題は「今のツリーが綺麗か」ではなく、一度でも外に出た鍵を、このまま信頼してよいかです。答えは「信頼しない」なので、最初の作業は失効です。

履歴を書き換える前に、漏れた鍵では署名できない状態にします。ここを後回しにすると、掃除しているあいだも同じ鍵が有効なままです。

「履歴から消したから、同じ鍵を使い続けてよい」にはしません。プライベートリポジトリでも同じです。

失効と並行して、まだ鍵ファイルが見える経路を閉じます。

失効したあとに、過去のコミットからもファイルを除去します。今のコミットから消すだけでは足りません。よく使うのは git filter-repo（または BFG）です。

# 例：特定ファイルを履歴全体から除去（実行前にバックアップを取る）
git filter-repo --path ios_distribution_private_key.pem --invert-paths

チーム開発なら、履歴改変の前に共有すること。個人リポジトリでも、clone し直す前提で進める。

履歴を書き換えたら、リモートに反映します。これは後始末で、失効の代わりにはなりません。

git push --force --all
# タグも使っている場合
git push --force --tags

ここまでで「今から clone する人」には見えにくくなります。ただし、すでに clone 済みの人・ミラー・キャッシュには残り得ます。だからこそ、先に失効させておく必要があります。

チェックの最後は、新しい証明書で Archive / TestFlight まで通るかです。

大企業のインシデント対応ほど形式ばらなくてよい一方で、次だけは省略しない方がよいです。

「プライベートだし、バレてないと思うからそのまま」は、後から効いてくるタイプの事故です。