Git status: проверка репозитория

git status

Команда git status отображает состояние рабочего каталога и раздела проиндексированных файлов. С ее помощью можно проверить индексацию изменений и увидеть файлы, которые не отслеживаются Git. Информация об истории коммитов проекта не отображается при выводе данных о состоянии. Для этого используется команда git log.

Связанные команды git

git tag
- Теги — это ссылки, указывающие на определенные точки в истории Git. Команда git tag обычно используется для захвата некой точки в истории, которая используется для релиза нумерованной версии (например, v1.0.1).
git blame
- Общее назначение git blame — отображение метаданных автора, связанных со строками, которые были внесены в файл при коммите. Таким образом можно проследить историю кода и выяснить, какой именно код был внесен в репозиторий, как это было сделано и по какой причине.
git log
- Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также проводить поиск по ней.

Использование

git status

Выводит список проиндексированных и неотслеживаемых файлов, а также файлов, удаленных из индекса Git.

Пояснения

Команда git status относительно проста в использовании. Она показывает, какие изменения были внесены с помощью команд git add и git commit. Сообщения о состоянии также содержат инструкции по индексированию файлов либо отмене этой операции. В примере выходных данных ниже показаны три основные категории вызова git status:

# On branch main
# 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

Игнорирование файлов

Неотслеживаемые файлы обычно подразделяются на две категории: файлы, недавно добавленные в проект и пока не отправленные в качестве коммитов, либо скомпилированные бинарные файлы (например, .pyc, .obj, .exe и т. д.). Включать файлы первой категории в выходные данные git status очень полезно, в то время как файлы второй категории могут затруднить отслеживание изменений в репозитории.

По этой причине в Git можно полностью игнорировать файлы, поместив пути к ним в специальный файл .gitignore. Каждый игнорируемый файл указывается в отдельной строке. При этом можно использовать символ * в качестве шаблона подстановки. Так, добавление следующего выражения в файл .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)

Первая строка данных о состоянии указывает на файл, который не был проиндексирован. Операция git add отражена во второй команде git status, а в последней строке данных сообщается, что элементы для коммита отсутствуют (рабочий каталог соответствует последнему коммиту). Для некоторых команд Git (например, git merge) требуется очистка рабочего каталога, чтобы исключить случайную перезапись изменений.

git log

Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также искать в ней конкретные изменения. С помощью git status можно просматривать рабочий каталог и раздел проиндексированных файлов, в то время как git log показывает только историю коммитов.

Существует множество вариантов для настройки выходных данных команды git log: от простой фильтрации коммитов до их отображения в пользовательском формате. Ниже показаны наиболее распространенные конфигурации git log.

Использование

git log

Выводит полную историю коммитов в стандартном формате. Если выходные данные занимают более одного экрана, можно выполнить прокрутку с помощью клавиши Пробел или нажать q для выхода.

git log -n <limit>

Ограничивает число коммитов с помощью параметра . Так, при указании git log -n 3 отобразится только 3 коммита.

Записывает каждый коммит в одну строку. Так можно получить подробный обзор всей истории проекта.

git log --oneline

git log --stat

Кроме обычных данных git log указывается, какие файлы были изменены, а также относительное число добавленных или удаленных строк в каждом из них.

git log -p

Выводит патчи, соответствующие определенным коммитам. Это самое подробное представление истории проекта, поскольку так можно просмотреть полный список изменений каждого коммита.

git log --author="<pattern>"

Выполняет поиск коммитов конкретного автора. Аргумент может быть обычной строкой или регулярным выражением.

git log --grep="<pattern>"

Выполняет поиск коммитов с сообщениями, соответствующими аргументу . Этот аргумент может быть обычной строкой или регулярным выражением.

git log <since>..<until>

Отображает только коммиты в диапазоне значений < since > и < until >. Эти аргументы могут быть идентификаторами коммитов, именами веток, указателями HEAD или другими ссылками на версии.

git log <file>

Выводит только коммиты, содержащие указанный файл. Так можно удобно просмотреть историю конкретного файла.

git log --graph --decorate --oneline

Здесь содержится несколько полезных параметров: флаг --graph создает основанную на тексте диаграмму коммитов в левой части области сообщений коммитов; флаг --decorate добавляет отображаемые имена веток или теги коммитов; флаг --oneline записывает информацию о коммите в одну строку, что позволяет без труда просматривать множество коммитов сразу.

Пояснения

Команда git log является основным инструментом Git для изучения истории репозитория. С помощью этой команды можно найти конкретную версию проекта или определить изменения, которые будут внесены при выполнении слияния в функциональной ветке.

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

Большая часть этой информации проста для понимания, но все же первую строку стоит пояснить. Строка длиной 40 знаков, следующая за элементом commit, является контрольной суммой SHA‑1 содержимого коммита. Она играет роль механизма для обеспечения целостности коммита (при нарушении целостности контрольная сумма изменится) и служит для него уникальным идентификатором.

Этот идентификатор может использоваться в таких командах, как git log .., в качестве ссылки на конкретные коммиты. Так, команда git log 3157e..5ab91 отображает данные в диапазоне между коммитами с идентификаторами 3157e и 5ab91. Кроме контрольных сумм, на конкретные коммиты указывают имена веток (см. раздел Модуль веток) и ключевое слово HEAD, которое всегда ссылается на текущий коммит, будь то ветка или конкретный коммит.

Символ ~ используется для относительных ссылок на родительский элемент коммита. Например, 3157e~1 ссылается на коммит, предшествующий коммиту 3157e, а HEAD~3 находится на 3 уровня выше текущего коммита.

Все перечисленные методы идентификации позволяют выполнять различные действия с конкретными коммитами. Обычно отправной точкой таких операций выступает команда git log, поскольку она позволяет найти нужные коммиты.

Пример

В разделе Использование приводится множество примеров использования git log, однако следует помнить, что в одной команде можно объединить несколько параметров:

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

Эта команда выводит данные по всем изменениям, которые Джон Смит внес в файл hello.py.

Синтаксис «..» удобно использовать при сравнении веток. В следующем примере показана команда для вывода краткого обзора всех коммитов, которые включены в ветку some-feature и не включены в main.