← ishizakahiroshi.com
失敗談 2026-09-07

公開リポジトリ 23 本の Git 履歴から個人アドレスを消した。コードには 1 文字も入っていなかった

消せない記録。封筒と署名欄をモチーフにしたヘッダー画像

朝 6 時半に外部から技術的な問い合わせが届いて、答えるために自分のリポジトリを開き直したら、別のことに気づきました。コードには個人用のメールアドレスが 1 文字も入っていません。載っていたのは commit の署名のほうでした。そこから公開リポジトリ 23 本の Git 履歴を書き換えることになり、問い合わせへの回答と並行して、着信から 2 時間 57 分で両方を終えた記録です。

Qiita で読む(技術版)→ note で読む(一般向け)→
記事全体の要約。コード 0 件とメタデータ 329 件、期間と切り替え日、消えた範囲と残った範囲、サポート依頼中の 4 点

記事全体の要約。数えた結果、期間、消えた範囲と残った範囲、そして今どこまで進んでいるか。

コードは綺麗でした。汚れていたのは署名です

Git の commit には author と committer という 2 つの署名が入ります。名前とメールアドレスと日時です。ファイルの中身とは別のところに、静かに、全部載っています。commit の URL の末尾に .patch を付ければ、認証なしで誰でも読めます。

README も、ソースも、設定ファイルも、ドキュメントも、package の metadata も、過去 commit のファイル内容も、全部 0 件でした。入っていたのは commit の署名と、注釈付きタグの tagger だけです。

旧アドレスがどこに入っていたか。ファイル内容 0 件、commit の署名 329 件、タグの tagger 3 リポジトリ。下段に月別の件数と切り替え日の縦線

ファイルの層は最初から綺麗で、汚れていたのはメタデータの層だけ。下段は月別の件数で、縦線が「開発用アドレスに切り替えたつもりだった日」。

「昔の分が残っていた」ではありませんでした

該当した commit は 329 件。いちばん古いのが 2026-04-25 で、いちばん新しいのが 2026-09-05 でした。気づいた日の 2 日前です。

開発用アドレスの初出は 2026-06-21 なので、6 月下旬には切り替えているつもりでいました。それでも 7 月に 35 件、8 月に 9 件、9 月に 2 件と混ざり続けています。切り替えたつもりで、切り替わっていなかった話でした。

force push しても、全部は消えません

23 本の書き換えと force push が全部通って、fresh clone して数え直したら、3 本だけ 0 件になっていませんでした。closed / merged 済み pull request の head ref に、その時点の履歴が凍結されていたからです。ここは GitHub 側が持っているもので、git からは書き換えも削除もできません。

公式ドキュメントに書かれているとおり、自分でできるところまでやって、残りは GitHub Support に依頼する 2 段構えが正規の手順でした。記事を書いている時点では回答待ちです。消えたとは書けません。

force push で消えたもの(branch・tag・タグの tagger)と、残ったもの(pull request の head ref、fork network、第三者のコピー、ローカル専用ブランチ)の対比

左が消えた範囲、右が残った範囲。右側は自分の手が届かないところです。

記事に書いたこと

Qiita 版には、実際に踏んだ穴を遭遇順に全部書きました。全 ref の force push が GitHub Actions を一斉に叩き起こすこと、archive 済みリポジトリは一時解除しないと push できないこと、メールのプライバシー設定を有効にしていると force push が全滅すること、対象をローカルのフォルダから数えると漏れること、バックアップを消える場所に置いていたこと。それと、削除依頼のサポートチケットの CC 欄に、消したいはずのアドレスが最初から入っていたことも。