Git でファイルが削除されたかどうかを確認する方法

はじめに

この実験では、Git リポジトリ内のファイルが削除されたかどうかを確認する方法を学びます。git log を使用して変更履歴を表示し、git status を使用して作業ディレクトリの現在の状態を確認するなど、削除されたファイルを特定するさまざまな方法を探ります。

実践的な手順を通じて、ファイルを作成、コミットしてから削除し、Git がこれらの変更をどのように追跡するかを観察します。具体的には、git log -- <file> を使用してファイルが削除されたコミットを確認し、git status を使用してコミット前の削除されたファイルを確認します。最後に、既存のファイルに対してこれらの方法をテストし、理解を深めます。

Skills Graph

git log -- <ファイル> を実行して削除を確認する

このステップでは、git log を使用してリポジトリ内の変更履歴を確認する方法を探ります。特に、ファイルの削除がどのように表示されるかに焦点を当てます。

まず、プロジェクトディレクトリにいることを確認しましょう。ターミナルを開き、次のコマンドを入力します。

cd ~/project/my-time-machine

次に、後で削除する新しいファイルを作成しましょう。このファイルを to_be_deleted.txt と名付けます。

echo "This file is temporary." > to_be_deleted.txt

ファイルが作成されたことを確認しましょう。

cat to_be_deleted.txt

次のように表示されるはずです。

This file is temporary.

ここで、このファイルをステージングエリアに追加し、コミットしましょう。これにより、Git の履歴にその存在が記録されます。

git add to_be_deleted.txt
git commit -m "Add a file to be deleted"

新しいコミットが作成されたことを示す、次のような出力が表示されるはずです。

[master <commit-id>] Add a file to be deleted
 1 file changed, 1 insertion(+)
 create mode 100644 to_be_deleted.txt

次に、rm コマンドを使用してファイルを削除しましょう。

rm to_be_deleted.txt

これで、ファイルシステムからファイルは削除されました。では、Git はこのことをどのように認識しているのでしょうか？状態を確認してみましょう。

git status

次のような表示がされるはずです。

On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    to_be_deleted.txt

no changes added to commit but untracked files present (use "git add" to track)

Git はファイルが削除されたことを正しく認識しています。これは、Git がファイルの状態を追跡しているからです。追跡対象のファイルが削除されると、Git はその変更を検出します。

次に、この削除をコミットしましょう。削除をステージングするために再び git add を使用し、その後 git commit を実行します。

git add to_be_deleted.txt
git commit -m "Delete the temporary file"

削除がコミットされたことを示す出力が表示されるはずです。

[master <commit-id>] Delete the temporary file
 1 file changed, 1 deletion(-)
 delete mode 100644 to_be_deleted.txt

最後に、git log を使用して履歴を確認しましょう。これには削除の記録も含まれます。

git log

2 つのコミットエントリが表示されます。最新のコミットには「Delete the temporary file」というメッセージが付いており、to_be_deleted.txt が削除されたことが示されています。

q を押してログビューを終了します。

これにより、Git がファイルの作成や変更だけでなく、削除も追跡し、プロジェクトの進化の完全な履歴を提供することがわかります。

git status を使用して削除されたファイルを管理する

このステップでは、git status が変更をコミットする前に削除されたファイルをどのように管理するのに役立つかをさらに探ります。

まだプロジェクトディレクトリにいることを確認しましょう。

cd ~/project/my-time-machine

前に to_be_deleted.txt を削除し、その削除をコミットしました。今度は別のファイルを作成し、削除のコミットを即座に行わずに削除しましょう。

another_file.txt という新しいファイルを作成します。

echo "This is another file." > another_file.txt

この新しいファイルを追加してコミットします。

git add another_file.txt
git commit -m "Add another file"

コミットが成功したことを確認する出力が表示されるはずです。

[master <commit-id>] Add another file
 1 file changed, 1 insertion(+)
 create mode 100644 another_file.txt

次に、rm コマンドを使用して another_file.txt を削除しましょう。

rm another_file.txt

これで、ファイルシステムからこのファイルは削除されました。リポジトリの状態を確認しましょう。

git status

今回の出力は次のようになります。

On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    another_file.txt

no changes added to commit but untracked files present (use "git add" to track)

Git が削除を認識し、another_file.txt を「Changes not staged for commit」の下にリストアップしていることに注意してください。これは、Git がファイルが削除されたことを認識しているが、この変更が次のコミットに含まれるようにまだ準備されていないことを意味します。

ここが重要なポイントです。ファイルシステムからファイルを削除しても、自動的に Git のステージングエリアに削除が反映されるわけではありません。この削除を履歴に記録することを明示的に Git に伝える必要があります。

git status コマンドは、リポジトリの現在の状態を確認するための窓口です。どのファイルが変更されたか、どのファイルが新規で追跡されていないか、どのファイルが削除されたかを教えてくれます。定期的に git status を確認することで、プロジェクトの変更を把握し、次のコミットに含める変更を決定することができます。

次のステップでは、削除されていない既存のファイルを Git がどのように扱うかを見ていきます。

既存ファイルのテスト

このステップでは、Git が既に追跡されているファイルの変更をどのように扱うかを見ていきます。

プロジェクトディレクトリにいることを確認しましょう。

cd ~/project/my-time-machine

最初の実験で作成してコミットした message.txt ファイルがあります。このファイルを変更しましょう。echo コマンドと >> を使って、既存のファイルにテキストを追加することができます。

echo "Hello again, Future Me!" >> message.txt

>> 演算子は、テキストをファイルの末尾に追加します。> を使うとファイル内容が上書きされますが、>> では上書きされません。

変更を確認するために、ファイルの内容を表示しましょう。

cat message.txt

次の 2 行が表示されるはずです。

Hello, Future Me
Hello again, Future Me!

次に、git status を使ってリポジトリの状態を確認しましょう。

git status

出力は次のようになります。

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   message.txt

no changes added to commit but untracked files present (use "git add" to track)

Git は message.txt が「modified（変更された）」ことを正しく認識しています。これは、作業ディレクトリ内のファイルの現在のバージョンと、最後のコミットに保存されているバージョンを比較するからです。

削除されたファイルの場合と同様に、Git は変更が「not staged for commit（コミットのためにステージングされていない）」ことを教えてくれます。つまり、ファイルを変更したが、次のセーブポイントにこれらの特定の変更を含めることを Git にまだ伝えていないということです。

これが Git の標準的なワークフローです。ファイルを変更し、git status を使って何が変更されたかを確認し、git add を使ってコミットしたい変更をステージングし、最後に git commit を使ってステージングされた変更をプロジェクトの履歴の新しいバージョンとして保存します。

git status の出力を理解することは、Git を効果的に使うための鍵です。これにより、プロジェクトの状態を明確に把握でき、変更を記録するために次に取るべきステップがわかります。

まとめ

この実験では、Git でファイルが削除されたかどうかを確認する方法を学びました。まず、ファイルを作成してコミットすることで、そのファイルをリポジトリの履歴に登録しました。次に、rm コマンドを使用してファイルを削除し、git status が削除を変更として正確に報告する様子を観察しました。最後に、削除をコミットして、このイベントを Git の履歴に記録しました。

これらの手順を通じて、Git がファイルの削除を追跡し、コミットする前に git status のようなツールを使ってこれらの変更を特定できることを理解しました。このプロセスは、Git がファイルの作成や削除などのライフサイクルイベントを記録していることを示しています。