無料の Git クライアントソフトウェア TortoiseGit で、git reset –hard コマンドと同様の処理をリビジョンログダイアログとそこから呼び出せるリセットダイアログを用いて行う手順を紹介します。
git reset –hard では、指定したコミットの状態に、HEAD (現在のコミット位置)、Index (ステージングエリアの状態) 以外に、作業ディレクトリのファイルの内容などもも全て戻します。
※ TortoiseGit-2.17.0.2-64bit を使用します。
前回の記事
前回は、TortoiseGit の RefLog ダイアログのリセットメニューを使って、 「git reset –soft ハッシュ値」コマンドと同等の処理を行い、 HEAD の指す現在のコミット位置を、２回目のコミット位置から最新の３回目のコミット位置に戻しました。
今回は git reset –hard コマンドと同等の TortoiseGit の機能を使って、コミットを削除します。
git reset –mixed について
git reset コマンドには、前回紹介した HEAD をリセットする –soft オプションと、今回紹介する –hard オプションの他に、 –mixed オプションがあります。
TortoiseGit の場合は、前回紹介した「リセット」ダイアログの soft, mixed, hard に対応します。
この –mixed オプションは、 HEAD の他に、ステージングエリアにあるコミット対象のファイル群の情報を持つインデックス (index) もリセットします。
しかし、現状、コミット直後は全てのコミット対象を確定するため、インデックスは空のコミットしかなく、まだ実践する状況がないので、引用にとどめます。
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
If
-Nis specified, removed paths are marked as intent-to-add (see git-add[1]).インデックスをリセットしますが、作業ツリーはリセットしません (つまり、変更されたファイルは保存されますが、コミットのマークは付けられません)。更新されなかったものを報告します。これはデフォルトのアクションです。
-N が指定されている場合、削除されたパスは追加意図としてマークされます (git-add[1] を参照)。
Git – git-reset Documentation と Google 翻訳
git reset –hard について
今回 TortoiseGit で行うリセット (Hard) に対応した git reset –hard コマンドは、作業ディレクトリのファイルなども指定したコミットの状態に巻き戻すため、前回行った –soft オプションによる reset よりも影響範囲が大きいです。
resetコマンドを使うと、3つのツリーを以下の順で上書きしていきます。どこまで上書きするかはオプション次第です。Git – リセットコマンド詳説
- HEAD が指し示すブランチを移動する (
--softオプションを使うと処理はここまで)- インデックスの内容を HEAD と同じにする (
--hardオプションを使わなければ処理はここまで)- 作業ディレクトリの内容をインデックスと同じにする
サンプルリポジトリ
公式サイト「Git – リセットコマンド詳説」でリセットの解説に用いるサンプルリポジトリの作り方が書かれています。
それを参考に TortoiseGit で作成したサンプルリポジトリのフォルダのコピーを使うので、サンプルリポジトリを作成していない場合は以下の記事を参照してください。
コマンドプロンプトで、作成したサンプルリポジトリのフォルダに移動して、 git log –oneline を入力すると、サンプルの通りにコミットした履歴や HEAD が指す現在のコミット位置が確認できます。
※ Windows 10 の場合は、エクスプローラのアドレスバーに cmd⏎ でそのフォルダを作業ディレクトリにしてコマンドプロンプトを開けます。
作成したサンプルリポジトリでは、３回のコミット履歴 (上の行が最新) があり、HEAD は最新の３回目のコミット位置を現在のコミット位置として指しています。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git log --oneline
fa795f0 (HEAD -> master) file.txt に 2 行目を追加
1f1f4dd file.txt に hello, world を追記。
e2829b8 file.txt をバージョン管理に追加します。git reset –hard と同等の TortoiseGit 機能によるコミットの戻し
サンプルリポジトリのフォルダをエクスプローラで開いて、右クリックして表示されるメニュー「 TortoiseGit」→「ログを表示」で、リビジョンログ（ログメッセージ）ダイアログを開きます。
先ほど git log –oneline コマンドで確認したとおり、３つのコミットの履歴が表示されました。
３回目のコミットから２回目のコミットに戻すために、２回目のコミットの行をを右クリックして表示されるメニュー「 “master” をここへリセット」を選択します。
※ master はブランチ名です。
リセットダイアログ（下図の右側）が表示されます。
「現在のブランチのリセット」枠では、「コミット」ラジオボタンが選択されていて、２回目のコミットを指すハッシュ (SHA-1) 値が設定されています。
このハッシュ値がどのコミットを指すかは、右側の 「…」 ボタンを押すと確認できます。
確認したら、「…」 ボタンで開いたダイアログを「キャンセル」ボタンで閉じます。
「リセットの種類」枠で Hard ラジオボタンを選択して OK ボタンを押すと git reset –hard ハッシュ値と同様の Hard リセットが行われます。
HEAD の変更だけの soft リセットと異なり、インデックス・作業ディレクトリも含めて作業ツリー全体が、指定したコミットの状態にリセットされて、ファイルが消えたり内容が変わる可能性があるので注意しましょう。
「git reset –hard –end-of-options ２回目のコミットのハッシュ値」コマンドが実行されました。
–end-of-options は、 git コマンドでそれ以降をオプションとして扱わないようにするオプションです。このあとに — から始めてもオプションとして扱われなくなります。
Because
--disambiguates revisions and paths in some commands, it cannot be used for those commands to separate options and revisions. You can use--end-of-optionsfor this (it also works for commands that do not distinguish between revisions in paths, in which case it is simply an alias for--).-- は一部のコマンドのリビジョンとパスの曖昧さを解消するため、これらのコマンドでオプションとリビジョンを区切るのに -- を使用することはできません。これには --end-of-options を使用できます (パス内のリビジョンを区別しないコマンドにも機能します。この場合、これは単なる -- のエイリアスです)。Git – gitcli Documentation
リセット（Hard) の確認
Hard オプションによるリセットで、最新の３回目のコミットから、２回目のコミットに作業ツリー全体を Hard リセットした後、先ほど開いたリビジョンログ（ログメッセージ）ダイアログを開いて最新のログを確認します。
すでにリビジョンログ（ログメッセージ）ダイアログを開いている場合は、左下の「更新」ボタンを押しましょう。
git log は、HEAD の指す現在のコミット以前のログだけを表示するため、最新の３回目のコミットが表示されなくなりました。
git log –oneline コマンドを実行すると、リビジョンログ（ログメッセージ）ダイアログと同じく HEAD の指す２回目のコミット以前のログだけが表示されました。
また、 Hard オプションのため、作業ディレクトリのファイルの内容も２回目のコミットの内容に戻されているため、 soft オプションで HEAD だけを移動したときとは異なり、差分は検知されていません。
G:\Dev\StudyTortoiseGit\Repo1ResetHard>git log --oneline
1f1f4dd (HEAD -> master) file.txt に hello, world を追記。
e2829b8 file.txt をバージョン管理に追加します。HEAD より新しいコミットは一定期間後に消えます
どのコミットからも到達不能になったコミット（例では最新の３回目のコミット）は、 reflog から一定期間後 (デフォルトでは 90 日後)に消されて、その結果 dangling commit (Google 翻訳：
ぶら下がりコミット) になり、 gc により削除されます。
それまでは、まだ３回目のコミット自体は存在します。
–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
まとめ
今回は、無料の Git クライアントソフトウェア TortoiseGit で、git reset –hard コマンドと同様の処理をリビジョンログダイアログとそこから呼び出せるリセットダイアログを用いて行う手順を紹介しました。
git reset –hard では、指定したコミットの状態に、HEAD (現在のコミット位置)、Index (ステージングエリアの状態) 以外に、作業ディレクトリのファイルの内容などもも全て戻すことを git log で確認しました。
参照サイト 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
記事一覧 → Compota-Soft-Press
コメント