リポジトリの検査

リポジトリの検査

git status

The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven’t, and which files aren’t being tracked by Git. Status output does not show you any information regarding the committed project history. For this, you need to use git log.

使用法

git status

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

ディスカッション

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

# ブランチ master に対して
# コミット対象の変更:
# ("git reset HEAD <file>..." を使用してアンステージ)
#
#変更済み: hello.py
#
# 変更はコミット用にステージングされません:
# ("git add <file>..." を使用してコミットするものを更新します)
# (作業ディレクトリの変更を破棄するには "git checkout -- <file>..." を使用します)
#
#変更済み: main.py
#
#未追跡ファイル:
# (コミットされるものに含めるには "git add <file>..." を使用します)
#
#hello.pyc

無視するファイル

Untracked files typically fall into two categories. They're either files that have just been added to the project and haven't been committed yet, or they're compiled binaries like .pyc, .obj, .exe, etc. While it's definitely beneficial to include the former in the git status output, the latter can make it hard to see what’s actually going on in your repository.

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

*.pyc

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

# hello.py の編集
git status
# hello.py は "Changes not staged for commit" の下に一覧表示されます
git add hello.py
git status
# hello.py は "Changes to be committed" の下に一覧表示されます
git commit
git status
# コミットするものはありません (作業ディレクトリはクリーンです)

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

git log

The git log command displays committed snapshots. It lets you list the project history, filter it, and search for specific changes. While git status lets you inspect the working directory and the staging area, git log only operates on the committed history.

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

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

使用法

git log

Display the entire commit history using the default formatting. If the output takes up more than one screen, you can use Space to scroll and q to exit.

git log -n <limit>

Limit the number of commits by <limit>. For example, git log -n 3 will display only 3 commits.

git log --oneline

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

git log --stat

Along with the ordinary git log information, include which files were altered and the relative number of lines that were added or deleted from each of them.

git log -p

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

git log --author="<pattern>"

Search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

git log --grep="<pattern>"

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

git log <since>..<until>

Show only commits that occur between <since> and <until>. Both arguments can be either a commit ID, a branch name, HEAD, or any other kind of revision reference.

git log <file>

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

git log --graph --decorate --oneline

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

ディスカッション

The git log command is Git's basic tool for exploring a repository’s history. It’s what you use when you need to find a specific version of a project or figure out what changes will be introduced by merging in a feature branch.

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

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

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

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

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

The Usage section provides many examples of git log, but keep in mind that several options can be combined into a single command:

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

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

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

git log --oneline master..some-feature

Git を学習する準備はできていますか?

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

今すぐ始める