以前のコードを読みたいだけなのに、ファイルを過去へ戻す操作をすると、今書いている変更と混ざることがあります。Gitのshowなら、指定したコミットのファイルを作業場所へ上書きせず表示できます。
業務ツールの修正では、前の設定例や入力検査を見比べたい場面があります。まず読むだけの操作で違いを確認し、必要な変更を決めてから編集すると、変更する範囲を追いやすくなります。
どの履歴のファイルを見るか
HEADは現在のコミット、HEAD~1はそこから最初の親を一つたどったコミットを指します。次の例はリポジトリのルートにあるtool.pyの履歴を調べる操作です。
git status --short
git log --oneline -- tool.py
git show 'HEAD~1:tool.py'
コミット:パスの形で、過去のファイル内容を指定します。PowerShellでは全体を引用符で囲み、ひとつの引数として渡しています。サブフォルダーなら、たとえばHEAD~1:scripts/tool.pyのように、Git上のパスを指定します。
HEAD~1は、そのファイルの直前の変更を自動で選ぶという意味ではありません。直前のコミットで別のファイルしか変わっていなければ、tool.pyは同じ内容かもしれません。git log -- tool.pyで変更履歴を見て、目的のコミットを選びます。
出力と作業中の内容を見比べる
練習用に、最初のコミットでmessage = 'before'、次のコミットでmessage = 'after'というtool.pyを作ったとします。二つ目のコミット上でgit show 'HEAD~1:tool.py'を実行すると、表示はbeforeです。現在のファイルはafterのままです。
さらに手元でmessage = 'working'へ編集していても、showによる履歴の表示がその変更を保存したり、取り消したりするわけではありません。前後でgit status --shortとファイルを確認すると、表示と復元の違いを確かめられます。
git show 'HEAD:tool.py'
git diff -- tool.py
git status --short
HEADの内容はコミットした状態、git diffは作業中との差を調べるものです。どちらを見ているかを分けてください。表示だけのつもりで>を付けて同じファイルへ書き出すと、シェルの出力先として上書きしてしまう場合があります。この例はコンソールへ表示するだけにしています。
ファイルが存在しない場合
指定したコミットより後にファイルが追加されたなら、その前の履歴にはありません。ファイル名を変えた場合も、選んだ時点のパスを確認します。現在のパスを指定しただけで、すべての名前変更を自動でたどれるとは考えないようにします。
パスが見つからないというエラーが出たら、コミット、リポジトリのルートからのパス、文字の大文字小文字を確認します。エラーを無視して、現在のファイルが過去の内容だとみなさないようにしてください。
履歴に保存されないもの
git showで読めるのは、Gitへ記録した内容です。無視している環境設定、実データ、仮想環境、送信済みのメール、データベースの中身まで過去へ戻るわけではありません。以前のコードが動いた条件は、READMEなどの記録とも照合します。
この操作例は新規の練習リポジトリで、過去内容を表示した前後の作業ファイルと状態が変わらないことを確認する範囲です。実務の履歴へ応用する場合も、表示結果を保存するのか、読み比べるだけなのかを先に分け、現在の変更を残したまま調べてください。
関連する記事
GitでPythonスクリプトを管理する基本｜戻せる作業環境を作る
Pythonスクリプトを配布する前に見ること｜設定ファイルとREADME
