リポジトリの検査

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 log コマンドでは、プロジェクト履歴の一覧表示、フィルター、および特定の変更内容の検索を行えます。

使用法

git status

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

ディスカッション

git status は比較的シンプルなコマンドです。このコマンドは、git addgit 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 log コマンドでは、プロジェクト履歴の一覧表示、フィルター、および特定の変更内容の検索を行えます。git status は作業ディレクトリとステージング エリアの状態を確認するためのものであるのに対し、git log はコミット済みの履歴のみを表示します。

Git チュートリアル:git status と git log

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

使用法

git log

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

git log -n <limit>

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

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

git log --oneline
git log --stat

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

git log -p

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

git log --author="<pattern>"

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

git log --grep="<pattern>"

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

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

~ 文字は、親コミットへの相対参照を行う場合に便利です。例えば、3157e~13157e の 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

git status を学ぶ準備はできましたか?

この対話式チュートリアルを利用しましょう。

今すぐ始める