Git log — как просматривать историю репозитория

• git log показывает историю коммитов в обратном хронологическом порядке; используйте форматирование и фильтры, чтобы увидеть только нужные данные.
• Частые комбинации: –oneline, –graph, –pretty=format:…, -p, –since/–until и ref1..ref2 для сравнения веток или тегов.
• Для подготовки релиз-нотов используйте git shortlog; для глубокого разбора — git show и git bisect.

Git предоставляет один из самых фундаментальных сервисов для команды — историю проекта. Поскольку Git отслеживает все изменения файлов в репозитории, он предлагает мощные возможности логирования. Одной командой можно запросить историю проекта множеством способов и вывести разные наборы данных.

Команда git log — самая объёмная среди обычных команд Git. Её мануал занимает тысячи строк, но полезного поведения можно получить из нескольких ключевых опций.

Короткое введение и терминология

• Коммит — снимок изменений с метаданными (автор, дата, сообщение).
• Хеш (SHA) — уникальный идентификатор коммита.
• Реф (reference) — ветка, тег или другой указатель на объект в Git.

Важно: git log — это скорее средство просмотра и фильтрации истории, а не инструмент изменения истории.

Базовое логирование по умолчанию

По умолчанию git log выводит список коммитов в обратном хронологическом порядке. Каждый коммит содержит хеш, автора, дату и сообщение коммита:

Команда использует пейджер (например less или more) для удобной навигации по выводу. В настройках Git можно указать другой пейджер (переменная core.pager) или отключить его, если нужно перенаправить вывод.

Пример вывода из репозитория исходного кода Git:

commit 670b81a890388c60b7032a4f5b879f2ece8c4558 (HEAD -> master, origin/next,
    origin/master, origin/HEAD)
Author: Junio C Hamano 
Date: Mon Jun 14 13:23:28 2021 +0900

The second batch

Signed-off-by: Junio C Hamano 

Разбор: первая строка — полный хеш и список веток/рефов, указывающих на этот коммит. Дальше — автор (имя и email), дата и сообщение коммита.

Опции git log делятся на две категории:

• Форматирование: как Git отображает каждый коммит.
• Фильтрация: какие коммиты включать в вывод.

Также к команде можно добавлять аргументы (файлы, коммиты, ветки), которые накладывают дополнительное ограничение.

Форматирование вывода git log

Ниже — распространённые способы изменить представление истории.

Короткий вывод — –oneline

Опция –oneline даёт компактный вывод: в каждой строке — сокращённый хеш и заголовок сообщения.

git log --oneline

Это удобный способ получить обзор последних коммитов:

Важно: в компактном виде теряется метадата (дата, автор), поэтому он хорош для обзора, но не для аудита.

Визуализация ветвления — –graph

Опция –graph рисует простую ASCII-графику, показывающую связи между ветками и слияниями.

git log --oneline --graph

Граф полезен, когда история сложная: он показывает ветвления, слияния и порядок коммитов.

Преднастроенные форматы — –pretty

Опция –pretty поддерживает несколько значений: short, oneline, fuller и кастомный формат format:.

git log --pretty=short

Это почти то же, что git log, но без полной даты и длинного сообщения.

git log --pretty=oneline

Эквивалент –oneline.

git log --pretty=fuller

Выведет более подробную информацию: отдельные поля для автора и коммиттера.

С помощью варианта format: можно задать набор плейсхолдеров для вывода. Распространённые плейсхолдеры:

• %H — полный хеш коммита
• %h — сокращённый хеш
• %ad — дата автора
• %ar — дата автора в относительном формате
• %s — заголовок сообщения
• %b — тело сообщения
• %p — сокращённые хеши родителей

Пример с цветом и краткой датой:

git log --pretty=format:'%C(auto) %h [%ad] %s' --date=short

Совет: если вывод собираетесь парсить скриптом, используйте явно разделители (например | или ) и фиксированный формат даты.

Показать изменения (diffs) — –shortstat и -p

Краткая статистика изменений добавляется через –shortstat:

git log --shortstat

После каждого коммита появится строка вида:

1 file changed, 48 insertions(+), 2 deletions(-)

Для подробных изменений используйте опцию -p, которая выводит полный патч для каждого коммита:

git log -p

-p полезен, когда нужно увидеть точные строки, которые были добавлены или удалены.

Фильтрация вывода git log

Даже при удобном формате весь вывод может быть слишком объёмным. Ниже — способы ограничить набор коммитов.

Ограничение количества

Чтобы показать только N последних коммитов, используйте синтаксис -N:

git log -2

Ограничение по дате

–since (или –after) и –until (или –before) принимают даты в формате ISO 8601. Можно указать только одно или оба.

git log --since="2021-01-01" --until="2021-05-01"

Git также поддерживает относительные даты: –since=”2 weeks ago”.

Важно: относительные даты зависят от локали и часов сервера; для скриптов предпочтительнее явные даты.

Ограничение по файлу

Чтобы увидеть, как менялся конкретный файл, добавьте его имя в конец команды:

git log filename

Вы увидите только коммиты, которые затронули filename.

Сравнение веток и диапазоны ссылок

Синтаксис ref1..ref2 позволяет посмотреть коммиты, присутствующие в одном рефе, но отсутствующие в другом.

1. Коммиты, которые есть в main, но не в branch:

git log --oneline origin/branch..origin/main

2. Коммиты, которые есть в branch, но не в main:

git log --oneline origin/main..origin/branch

3. Коммиты, которые уникальны для одной из веток (симметричная разница):

git log --oneline origin/branch...origin/main

То же работает для тегов и любых других рефов:

git log --abbrev-commit --pretty=format:'%h %ar %s' v2.32.0-rc3..v2.32.0

Смежные команды

• git shortlog — агрегирует коммиты по авторам, удобен для релиз-нотов:

git shortlog v2.32.0-rc3..v2.32.0

• git show — показывает подробности конкретного объекта (коммита, тега, дерева). Поддерживает многие опции git log.
• git bisect — более автоматизированный подход для поиска коммита, который ввёл регресс.

Когда git log не хватает

Важно понимать пределы git log:

• Для поиска регрессий удобнее git bisect, который автоматизирует бинарный поиск «худого» коммита.
• Для анализа связей между репозиториями/форками может понадобиться смотреть pull request-метаданные на платформе (GitHub/GitLab), потому что они содержат контекст, не вшитый в сами коммиты.
• Если история переписана (rebase, filter-branch), хеши изменятся, и старые ссылки станут недоступны.

Практическое руководство: паттерны использования

Ниже — набор проверенных паттернов и готовых команд (cheat sheet).

Cheat sheet — полезные команды

• Быстрый обзор последних 10 коммитов:

git log --oneline -10 --graph --decorate

• Подробный вывод с патчами за последний день:

git log --since="1 day ago" -p

• Коммиты, затронувшие конкретный файл, за месяц:

git log --since="30 days ago" -- filename

• Коммиты между двумя ветками в кратком формате:

git log --oneline origin/main..origin/feature-branch

• Форматированный вывод для парсинга (табуляции и дата ISO):

git log --pretty=format:"%h\t%ad\t%an\t%s" --date=iso

Пример: подготовка релиз-нотов

Шаблон процесса:

1. Определите диапозон: v1.2.0..v1.3.0
2. Соберите коммиты в компактном виде:

git log --pretty=format:"%h %s" v1.2.0..v1.3.0

3. Сгруппируйте по авторам или категориям (git shortlog помогает автоматически):

git shortlog v1.2.0..v1.3.0

4. Для важных изменений приложите диффы (git show или -p).

Роли и чек-листы

Разные роли в команде используют git log по-разному. Короткие чек-листы помогут не забыть важное.

Разработчик — быстрый обзор

• git fetch && git log –oneline origin/main..HEAD
• Проверить последние изменения в файлах, над которыми работаешь: git log – filename
• Убедиться, что в коммитах есть понятные сообщения

Ревьювер — подготовка к ревью

• git log –pretty=fuller –author=”Имя” –since=”2 weeks ago”
• Просмотреть патчи: git log -p – filename
• Проверить точки слияния: git log –graph –oneline –decorate

Релизный инженер

• Сформировать диапазон релиза: git log –oneline vX.Y.Z..vX.Y.Z+1
• Сгруппировать по авторам: git shortlog
• Составить список breaking changes через ключевые слова в сообщениях (manual)

SOP: как оформить git log для релиза (шаблон)

1. Определить start_tag и end_tag.
2. Собрать сводку:

git log --pretty=format:"%h %ad %an %s" --date=short start_tag..end_tag > release-commits.txt

3. Сгруппировать по теме вручную или в CSV для автоматической обработки.
4. Для каждого breaking change приложить подробный патч: git show .
5. Подготовить draft релиз-нотов и передать на финальную проверку.

Incident runbook: как быстро найти коммит, вызвавший регрессию

1. Убедитесь, что тест воспроизводит регрессию на двух ревизиях (хорошая и плохая).
2. Запустите git bisect:

git bisect start
git bisect bad HEAD
git bisect good 
# Следуйте подсказкам, запускайте тесты, помечайте bad/good

3. Когда bisect вернёт коммит, изучите его через git show и git log -p ~1.. .
4. При необходимости откатите изменения или создайте PR с фиксами.

Примечание: git bisect автоматизирует половинный поиск, но требует надёжного теста.

Проверки и критерии приёмки

Критерии приёмки для вывода истории (пример для инструмента интеграции):

• Вывод должен содержать хеш, дату, автора и заголовок.
• Для парсинга должна быть опция с фиксированным разделителем (например \t).
• У диапазонных запросов (ref1..ref2) результат должен соответствовать локальному и удалённому состоянию веток после git fetch.

Ментальные модели и эвристики

• История — это поток изменений: думайте о ней как о журнале, а не как о команде undo.
• Малые, атомарные коммиты проще читать и ревьюить. Если коммит затрагивает более одной логической задачи — лучше разбить.
• Используйте дескриптивные сообщения: «Fix X» плохо, «Fix null-pointer when parsing user input in widget Y» — хорошо.

Факт-бокс: ключевые подсказки

• По умолчанию git log выводит коммиты в обратном хронологическом порядке.
• –oneline сокращает вывод до одной строки на коммит.
• –graph показывает ASCII-граф ветвления.
• -p выводит полный патч.
• ref1..ref2 показывает коммиты, присутствующие в ref2, но отсутствующие в ref1.

Примеры шаблонов команд (templates)

• Однострочный лог с датой ISO и автором:

git log --pretty=format:"%h\t%ad\t%an\t%s" --date=iso

• Лог с изменениями количества строк:

git log --pretty=oneline --shortstat

• Точно отформатированный CSV для импорта в таблицу:

git log --pretty=format:'"%h","%ad","%an","%s"' --date=iso > commits.csv

Тест-кейсы и приёмка для автоматической интеграции

• Тест 1: git log –oneline -n 5 возвращает ровно 5 строк.
• Тест 2: git log –since=”2021-01-01” не содержит коммитов с датами раньше указанной.
• Тест 3: git log – filename возвращает только коммиты, где filename отображается в изменениях.

Краткий глоссарий: 1 строка термина — значение

• Коммит — атомарная запись изменений в репозитории.
• Хеш — уникальный идентификатор коммита (SHA).
• Реф — ссылка (ветка, тег) на объект в Git.
• Патч — список изменений, обычно в формате unified diff.

Mermaid: решение что использовать

flowchart TD
  A[Нужно просмотреть историю?] --> B{Цель}
  B -->|Быстрый обзор| C[--oneline --graph]
  B -->|Релиз-ноты| D[git shortlog + форматирование]
  B -->|Разбор конкретного изменения| E[-p или git show ]
  B -->|Нужно найти регрессию| F[git bisect]
  E --> G[Детальный анализ]
  D --> H[Сбор в файл и ручная группировка]

Заключение

Git log — мощный инструмент для исследования истории проекта. Научившись комбинировать форматирование и фильтры, вы сможете быстро отвечать на вопросы: кто изменил файл, когда была внесена правка, какие изменения лежат между релизами и т. д. Для подготовки релиз-нотов и аудита истории используйте git shortlog и шаблоны форматирования. Для поиска регрессий — git bisect. Наконец, придерживайтесь хороших практик коммит-месседжей и атомарности изменений: это заметно упростит анализ истории всем членам команды.

Важно: всегда делайте git fetch перед сравнением удалённых рефов.

Примечание: если история переписывалась (rebase, filter-branch, git filter-repo), хеши изменятся — учтите это при наведении порядка в репозитории.