Gitで意図しないアカウントでコミットしてしまった時の修正方法【備忘録】
Gitで意図しないアカウントでコミットしてしまった時の修正方法【備忘録】
複数プロジェクトを同じPCで扱っていると、意図しない別のアカウント（ユーザー名・メールアドレス）でGitコミットを作成し、そのままリモートにアップロード（push）してしまう事故が起きがちです。また、その際に.gitignoreの設定漏れで不要な巨大ディレクトリ（venvなど）まで巻き込んでしまうケースもあります。
今回は、そんなやらかしをなかったことにするための**Git修正作業の備忘録（今回実際に使ったコマンドまとめ）**です。
1. アカウントの確認と再設定
まずは現状のアカウントを確認し、正しいアカウントに設定し直します。
Gitのアカウント確認
現在の設定を確認するには以下のコマンドを使用します。
git config user.name
git config user.email
Gitのアカウント設定（リポジトリ単位）
特定のリポジトリのみでアカウントを切り替えたい場合はこちら。
git config user.name "正しい名前"
git config user.email "正しいメール"
Gitのアカウント設定（PC 全体）
グローバル（PC全体）のデフォルト設定を上書きする場合はこちら。
git config --global user.name "正しい名前"
git config --global user.email "正しいメール"
2. コミット履歴（Author）の修正
設定を直しても過去のコミット履歴はそのままなので、rebaseを使って過去にさかのぼってAuthor（作成者）を修正します。
コミット一覧の確認（Authorとメールアドレス）
誰のアカウントでコミットされているかをコンパクトな一覧で確認します。
git log --pretty=format:"%h %an <%ae>"
全履歴を編集状態にする（first commit を含む）
最初のコミットまでさかのぼって変更を加えたい場合は --root を指定します。エディタが開くので、修正したいコミットの pick を edit に書き換えて保存します。
git rebase -i --root
[!補足] 複数コミットを edit する場合の注意点！
- 同じコミットを複数回 edit にすると rebase が壊れる
- amend する内容がないと continue できず詰む
すべての履歴ではなく、直近の数コミットだけ修正したい場合は、
--rootをつけずにgit rebase -i HEAD~n(nはさかのぼるコミット数) で編集範囲を指定する。
コミットのAuthorを修正する
rebaseで対象のコミットで停止したら、以下のコマンドでAuthorを新しいものに書き換えます。
git commit --amend --author="正しい名前 <正しいメール>"
rebase関連の操作コマンド
修正が終わったら continue で進めます。途中でよく使うコマンドは以下の通りです。
# 次のコミットへ進む
git rebase --continue
# rebase 作業を中止して元に戻す
git rebase --abort
# そのコミットの変更をスキップする
git rebase --skip
3. 巨大ファイル（venv等）の削除と履歴からの完全抹消
誤ったコミットの中に、venvなどの容量が大きすぎる不要ファイルが含まれていた場合の対処法です。
venv をGitの管理から外す
まずは現在のインデックスから削除し、物理ディレクトリも消します。
git rm -r --cached venv
rm -rf venv
.gitignore に追加
再び管理対象に入らないように、.gitignoreに追記しておきます。
既にある場合は重複に注意。
echo "venv/" >> .gitignore #初回のみ
(ファイルに直接 venv/ と書き込んでもOKです)
履歴から巨大ファイルを完全削除（filter-repo）
上記だけでは過去のGit履歴（オブジェクト）の中に巨大ファイルが残ってしまうため、filter-repoという強力なツールで履歴から完全に消しさります。
① filter-repoのインストール
pip install git-filter-repo
② venvを履歴から完全削除
git filter-repo --path venv --invert-paths
[!注意]
- filter-repo は 履歴を完全に書き換えるため、GitHub の PR や Fork が壊れる
- チーム開発では要注意
- GitHub Desktop では動作しない場合がある
4. GitHub リモートリポジトリへ反映
ローカルでの履歴の改変（rebase や filter-repo）が終わったら、リモート（GitHub等）の内容をこれらで上書きします。
[!注意] 強制プッシュは共同開発者の変更を上書きしてしまう危険があるため、チーム開発の場合は注意して実行してください。
git push --force
5. 履歴が壊れた時の復旧方法
git rebaseの最中に手順を間違えてよく分からなくなったり、意図せずコミットを消してしまった場合でも、以下の方法で元の状態に復旧できることが多いです。
① rebase の中断（よく分からなくなった場合）
git rebase中であれば、以下のコマンドでrebaseを開始する前の状態に安全に戻すことができます。
git rebase --abort
② reflog で過去の状態にタイムスリップする
rebaseを完了させてしまった後や、間違えて強制プッシュする前の状態に戻したい場合は、Gitの隠し履歴（reflog）を使うのが最強の復旧方法です。
# これまでの全操作履歴（ハッシュとHEAD@{n}）を表示
git reflog
# 戻りたい状態のHEAD（例: HEAD@{2}）を指定して強制リセット
git reset --hard HEAD@{2}
③ リモート（GitHub）の履歴でローカルを上書きする
ローカルの変更が完全に壊れてしまい、リモート（GitHubなど）の内容がまだ無事（push --force前）であるなら、リモートの状態をそのまま引っ張ってくるのが確実です。
git fetch origin
git reset --hard origin/main
6.GitHub Contributorsの表示名が直らない時の対処法
author を修正しても Contributors は以下の理由ですぐに消えません。
- GitHub は Contributors をキャッシュしている
- 反映まで数時間〜1日かかる
- 過去のコミットに古いメールが残っていると消えない
過去のコミットに古いメールが残っているかの確認方法は下記のコマンドで確認できます。
git log --pretty=format:"%h %an <%ae>"
以上の手順を踏むことで、「間違ったアカウントでのコミット」や「巨大ファイルの混入」といったGitの履歴事故を、綺麗に修正してリモートに反映させることが可能です。困ったときの参考にしてください！