プログラムなどのバージョン管理を行える、無料のソースコード管理 (SCM: software configuration management) ソフト Git で、他のコミットから到達不能になったコミット（dangling commit）を gc (garbage collect) の機能ですぐに削除する手順の例を紹介します。
※定期的に行われる gc auto で一定期間（reflog から破棄されるデフォルトの期間は 90 日）の後に dangling commit は自動的に削除されます。
※Git-2.49.0 (64 bit) を使用します。
前回の記事
前回は、どのコミットからも到達不能になり削除される対象になった dangling commit を、削除される前に復旧する手順の例を紹介しました。
今回は、 dangling commit を git gc を用いてすぐに削除する手順を紹介します。
※定期的に行われる gc auto で一定期間（reflog から破棄されるデフォルトの期間は 90 日）の後に dangling commit は自動的に削除されます。
Git gc は自動的に dangling commit を削除します
自身以外のコミットから到達不能なコミット (dangling commit) は、自動的に行われる auto gc によって削除されます。
Gitは時々 “auto gc” と呼ばれるコマンドを自動的に実行します。
“gc” はガベージコレクト（garbage collect）を意味します。このコマンドは幾つものことを行います。
さらにどのコミットからも到達が不可能かつ数ヶ月間更新がないオブジェクトを削除します。
Git – メンテナンスとデータリカバリ
dangling commit になる条件の１つは、 reflog の記録からそのコミットが消去されることです。
他のコミットから到達不能になったあと、デフォルトでは 90 日間で reflog からそのコミットは消去されます。
そのあとの auto gc のタイミングで dangling commit は削除されます。
–expire=<time>
Prune entries older than the specified time. If this option is not specified, the expiration time is taken from the configuration setting
gc.reflogExpire, which in turn defaults to 90 days.--expire=allprunes entries regardless of their age;--expire=neverturns off pruning of reachable entries (but see--expire-unreachable).指定された時間より古いエントリをプルーニングします。このオプションが指定されていない場合、有効期限は構成設定 gc.reflogExpire から取得され、デフォルトでは 90 日になります。 --expire=all は、経過時間に関係なくエントリを削除します。 --expire= は、到達可能なエントリのプルーニングをオフにすることはありません (ただし、--expire-unreachable を参照してください)。Git – git-reflog Documentation と Google 翻訳
サンプルリポジトリのログの確認
前回の結果を git log –oneline コマンドで確認します。
前回作成した new-branch ブランチの３回目のコミットが、 HEAD の参照先（＝現在のコミット位置）に設定されています。
ログでは、現在のコミット以前の３つのコミットが表示されています。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git log --oneline
fa795f0 (HEAD -> new-branch) file.txt に 2 行目を追加
1f1f4dd file.txt に hello, world を追記。
e2829b8 file.txt をバージョン管理に追加します。コミットを削除するため再び dangling commit にする
今回は、HEAD の参照先に設定されている new-branch ブランチの３回目のコミットを dangling commit にして、 gc を使ってすぐにそのコミットオブジェクトを削除します。
最新のコミットを dangling commit にする手順は、前回の記事でも紹介しています。
https://compota-soft.work/wp1/wp-admin/post.php?post=53860&action=edit
サンプルリポジトリのフォルダをエクスプローラで開いて、右クリックして表示されるメニュー「TortoiseGit」→「ログを表示」を選択します。
表示された「リビジョンログ（ログメッセージ）」ダイアログの上側に表示されている３つのコミットの行のうち、最新より１つ前の２行目のコミットを右クリックして表示されるメニュー「”new-branch” をここへリセット」を選択します。
※コミットは上側の行の方が最新です。
※ new-branch は現在のコミットが割り当てられているブランチ名です。
「リセット」ダイアログが表示されます。
「現在のブランチのリセット」枠は、「コミット」ラジオボタンが選択されていて、２回目のコミットを指すハッシュ値 (SHA-1) が入力されています。
※ハッシュ値が指すコミットについては、右側の … ボタンから確認できます。
「リセットの種類」枠で Hard ラジオボタンを選択すると、作業ツリーの全ての要素（HEAD, インデックス, 作業ディレクトリ）が指定されたコミットの状態にリセットされます。
設定が完了したら、 OK ボタンでリセット (Hard) を行います。
git reset --hard コミット位置のハッシュ値のコマンドが実行されました。「閉じる」ボタンで閉じます。
※ –end-of-options は前回紹介したように、それ以降の — をオプション表記とみなさないオプションです。
「リビジョンログ（ログメッセージ）」ダイアログを再び表示して確認すると、２回目のコミット位置へリセットしたため、それより後にコミットされた３回目のコミットの行は表示されなくなりました。
git による log と dangling commit の確認
最新の３回目のコミット位置から、リセット (Hard) で２回目のコミットの状態にしたあとのサンプルリポジトリで
git log --onelineでログを確認すると、 HEAD 以前のコミットだけが表示され、３回目のコミットは表示されなくなりました。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git log --oneline
1f1f4dd (HEAD -> new-branch) file.txt に hello, world を追記。
e2829b8 file.txt をバージョン管理に追加します。しかし、 reflog には new-branch ブランチ上に、３回目のコミットの参照履歴が記録されています。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git log --reflog --oneline
f960404 (master) 最新のコミットの１つ前のコミットから、新たに別のコミットを行います。
fa795f0 file.txt に 2 行目を追加
1f1f4dd (HEAD -> new-branch) file.txt に hello, world を追記。
e2829b8 file.txt をバージョン管理に追加します。そのため、
git fsck --fullで、到達不能なコミット（dangling commit）を調べても、検出されませんでした。
３回目のコミットはまだ dangling commit になっていません。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git fsck --full
Checking object directories: 100% (256/256), done.そこで、reflog からも、３回目のコミットの情報を消します。
git reflog expire --expire-unreachable=now --allを使って、到達不能なコミットを reflog の記録から削除します。
git log --reflog --onelineで確認すると reflog にさっきはあった「fa795f0 file.txt に 2 行目を追加」という３回目のコミットの行がなくなっています。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git reflog expire --expire-unreachable=now --all
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git log --reflog --oneline
f960404 (master) 最新のコミットの１つ前のコミットから、新たに別のコミットを行います。
1f1f4dd (HEAD -> new-branch) file.txt に hello, world を追記。
e2829b8 file.txt をバージョン管理に追加します。
reflog から到達不能なコミット記録を削除したあとの確認
reflog から到達不能なコミットの記録を削除した後に再び
git fsck --fullで dangling commit を調べると、「dangling commit ３回目のコミットのハッシュ値」が表示されました。
削除したい３回目のコミットが dangling commit になりました。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git fsck --full
Checking object directories: 100% (256/256), done.
dangling commit fa795f083559ba016c00be644bd24601ac587f41gc で dangling commit を削除
あとは、何もしなくても gc (garbage collect) の機能で自動的に削除されるのですが、いつ行われるかはわかりません。
今回は、こちらからコマンドを実行して、即時 dangling commit を削除します。
※gc によって削除されたコミットはおそらく復元できません。
git gc --prune=nowを実行すると、すぐに dangling commit は削除されます。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git gc --prune=now
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (7/7), done.
Total 7 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)dangling commit を削除した後に、再び
git fsck --fullで dangling commit を調べると、削除されたため、検出されませんでした。
#Verifying などのメッセージが増えていますが、これは削除に伴って、整合性を確認する処理を行ったようです。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (7/7), done.
Verifying commits in commit graph: 100% (3/3), done.
まとめ
今回は、プログラムなどのバージョン管理を行える、無料のソースコード管理 (SCM: software configuration management) ソフト Git で、他のコミットから到達不能になったコミット（dangling commit）を gc (garbage collect) の機能ですぐに削除する手順の例を紹介しました。
参照サイト Thank You!
- Git
- TortoiseGit – Windows Shell Interface to Git
- Git – リセットコマンド詳説
- リビジョングラフ
- リビジョンログダイアログ
- Git – git-log Documentation
- Git – git-reset Documentation
- Git – git-checkout Documentation
- Git – git-reflog Documentation
- Git – gitcli Documentation
- Git – メンテナンスとデータリカバリ
記事一覧 → Compota-Soft-Press
コメント