Git のステータス: リポジトリの検査

git status

git status は、作業ディレクトリの状態とステージングエリアの状態を表示するコマンドです。このコマンドを実行すると、どの変更がステージング済みでどの変更がまだステージングされていないのか、どのファイルが Git の追跡対象外になっているのかが表示されます。このステータス情報出力には、コミット済みの変更履歴に関する情報は含まれません。この情報を含めるには git log を使う必要があります。

関連する git コマンド

• git tag
  タグは Git 履歴のある時点をポイントする ref です。通常は git tag を使ってマーク付きバージョンリリース (例: v1.0.1) で使う履歴のある時点をキャプチャします。
• git blame
  • git blame の基本的な機能はファイルでコミットされている特定の行の作成者メタデータを表示することです。これにより、特定のコードの履歴を確認し、どんなコードがどのようにして、どんな理由でリポジトリに追加されたのかがわかるようになります。
• git log
  • git log コマンドではコミット済みのスナップショットが表示されます。プロジェクト履歴を一覧表示してそれをフィルタリングし、特定の変更を検索することができます。

使用法

git status

ステージングされているファイル、ステージングされていないファイル、追跡対象外のファイルを一覧表示します。

ディスカッション

git status は比較的シンプルなコマンドです。このコマンドは、git add と git commit の実行結果を表示します。ステータスメッセージには、ステージングされたファイルとステージングされていないファイルの関連情報も含まれます。以下のサンプル出力には、git status を実行したときの 3 つの主要カテゴリーが示されています。

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc

無視するファイル

追跡対象外のファイルには通常 2 つの種類があります。ひとつはプロジェクトに追加されたばかりでまだ一度もステージされたことがないファイル、もうひとつは .pyc、.obj、.exe 等の拡張子を有するコンパイル済みバイナリーファイルです。前者については git status コマンドの出力に含めることは有用ですが、後者は作業ディレクトリの状況確認の邪魔になる場合があります。

このため Git では、.gitignore という名称の特殊ファイルにパスを記述することによって、ファイルを表示対象から完全に除外できるようにしています。除外するファイルは、1 行に 1 つずつ記述する必要があります。またワイルドカードとして、* 記号を使用できます。例えば、次の行をプロジェクトのルートにある .gitignore ファイルに追加すると、コンパイル済みの Python モジュールが git status に表示されなくなります。

*.pyc

例

変更をコミットする前にリポジトリの状態を確認するようにしましょう。そうすれば、誤って意図しないものをコミットすることを防ぐことができます。次の例は、スナップショットのステージングおよびコミットの前と後のリポジトリの状態を示しています。

# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)

最初のステータス出力では、ファイルがステージングされていないことが示されています。2 番目の git status には、git add アクションの結果が反映されており、最後のステータス出力では、コミットするべきファイルは何も残っていないこと、つまり作業ディレクトリの状態は直前のコミットの結果と一致している (クリーンである) ことが示されています。Git コマンドの中には、変更を誤って上書きすることを防止するため、作業ディレクトリがクリーンな状態でなければ使用できないものがあります (git merge など)。

git log

git log は、コミット済みのスナップショットを表示するコマンドです。このコマンドを使用することにより、プロジェクト履歴の一覧表示、特定の変更内容の検索を行うことができます。git status コマンドは作業ディレクトリとステージングエリアの状態を確認するためのものであるのに対し、git log コマンドはコミット済みの履歴 (コミット履歴) のみが対象です。

ログ出力は、単にコミット履歴にフィルターをかけるだけの表示から完全にユーザー定義形式による表示まで、さまざまなカスタマイズが可能です。git log コマンドの一般的な設定例を以下に示します。

使用法

git log

コミット履歴全体をデフォルトの形式で表示します。出力表示が 2 ページ以上にわたる場合はスペースキーでスクロールが可能です。終了する場合は q を入力します。

git log -n <limit>

表示するコミット数を <limit> で制限します。例えば git log -n 3 とすると、表示するコミット数は 3 です。

git log --oneline

各コミットを 1 行にまとめます。これは、プロジェクト履歴のおおまかな概要を取得するのに便利です。

git log --stat

通常の git log 情報に加えて、改変されたファイルおよびその中での追加行数と削除行数を増減数で表示します。

git log -p

各コミットを表すパッチを表示します。これは、各コミットの完全な差分を表示します。プロジェクト履歴で取得可能な最も詳細なビューです。

git log --author="<pattern>"

特定の作成者が行ったコミットを検索します。引数 <pattern> にはプレーンテキストまたは正規表現を用いることができます。

git log --grep="<pattern>"

コミットメッセージが <pattern> (プレーンテキストまたは正規表現) と一致するコミットを検索します。

git log <since>..<until>

<since> と <until> の間に位置するコミットのみを表示します。2 個の引数には、コミット ID、ブランチ名、HEAD、その他任意のリビジョンリファレンスを用いることができます。

git log <file>

指定されたファイルを含むコミットのみを表示します。これは、特定のファイルの履歴を確認する簡単な方法です。

git log --graph --decorate --oneline

考慮すべきいくつかの役立つオプションがあります。--graph フラグを指定すると、コミットメッセージの左側にテキストベースのコミットの図が描画されます。--decorate はブランチの名前または表示されるコミットのタグを追加します。--oneline は、一目で簡単にコミットを参照できるように単一行にコミット情報を表示します。

ディスカッション

git log コマンドは、Git におけるコミット履歴を調べるための基本ツールです。このコマンドを使用すると、プロジェクトの特定のバージョンを見つけ出したり、フィーチャーブランチにマージすると何が変わるのか理解したりできます。

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

ほとんどの情報は直観的に理解できますが、最初の行には説明が必要でしょう。commit に続く 40 文字からなる文字列は、コミット内容の SHA-1 チェックサムです。チェックサムには 2 つの目的があります。1 つは、コミットの完全性を保証することです。コミットが破損している場合、異なるチェックサムが生成されます。もう 1 つは、各コミットの一意の ID を提供することです。

この ID を git log <since>..<until> のようにコマンド内で使用すると、特定のコミットを参照できます。例えば、git log 3157e..5ab91 を実行すると、ID が 3157e と 5ab91 の間に収まるすべてのコミットが表示されます。また、個々のコミットを参照する一般的な方法として、チェックサム以外に、ブランチ名 (ブランチの章をご覧ください) と HEAD キーワードを使用することもできます。HEAD は、ブランチであるか特定のコミットであるかを問わず、常に現在のコミットを参照します。

~ 文字は、親コミットへの相対参照を行う場合に便利です。例えば、3157e~1 は 3157e の 1 世代前のコミットを参照し、HEAD~3 は現在のコミットの「曽祖父母」(3 世代前) にあたるコミットを意味します。

このような方法でコミットを指定できるようにしているのは、特定のコミットを基準にして作業を行えるようにするためです。作業の出発点として git log コマンドを使用すれば、目的のコミットを効率よく探し出すことができます。

例

使用法のセクションでは、git log の用例を多数説明しましたが、ひとつのコマンドに複数のオプションを組み合わせて指定できることに留意してください:

git log --author="John Smith" -p hello.py

このコマンドを実行すると、John Smith がファイル hello.py に加えたすべての変更の全差分が表示されます。

.. 構文は、ブランチを比較する場合に便利です。次の例は、some-feature ブランチにあって master ブランチにはないすべてのコミットの概要を表示します。

git log --oneline master..some-feature