Самая базовая команда - git log. Без аргументов выводит коммиты с автором, датой, полным сообщением. Это годится, чтобы посмотреть «что было недавно», но для расследования нужны другие форматы.

git log --oneline                   # один коммит - одна строка

git log --oneline --graph --all     # с графом всех веток

git log --oneline -10               # последние 10

git log --stat                      # с файлами и числами изменений

git log -p                          # с полным diff каждого коммита

git log -p -- src/parser.py        # diff'ы коммитов, тронувших файл

Особенно полезно --graph --all --oneline в сочетании с --decorate:

git log --oneline --graph --all --decorate

# * a1b2c3d (HEAD -> main, origin/main) Merge feature/login

# |\

# | * e4f5a6b (feature/login) Fix typo

# | * 7a8b9c0 Add login form

# |/

# * b1c2d3e Initial commit

--decorate показывает ветки и теги. Многие настраивают это как alias:

git config --global alias.lg \

  "log --graph --oneline --decorate --all"

После этого git lg - однокомандный обзор истории.

Кастомный формат через --pretty:

git log --pretty=format:"%h %ad %s [%an]" --date=short

# a1b2c3d 2026-05-15 Add login form [Dmitry]

# e4f5a6b 2026-05-14 Initial commit [Olya]

Все placeholder'ы (%h, %ad, %s, %an, %ae, и т.д.)

• в man git-log.

См. log.

git log поддерживает фильтры. Самые частые:

# По автору

git log --author="Dmitry"

git log --author="@example.com"     # частичное совпадение в email

# По дате

git log --since="2026-01-01"

git log --until="2026-03-15"

git log --since="2 weeks ago"

# По сообщению коммита

git log --grep="JIRA-1234"          # рег.выражение

git log --grep="fix" --grep="auth" --all-match  # И-условие

# По пути файла

git log -- src/parser.py

git log -- "**/*.py"

git log --follow src/renamed.py     # с историей переименований

# По ветке

git log main..feature               # коммиты на feature, не на main

git log feature ^main               # то же самое в другой записи

# По количеству изменённых файлов

git log --max-count=20

# Mergi-коммиты только / без них

git log --merges

git log --no-merges

Комбинируются друг с другом. «Все багфиксы Димы за последний квартал в auth»:

git log --author="Dmitry" \

        --since="3 months ago" \

        --grep="^fix" \

        -- src/auth/

Это типичный paragraph любого исследования. Запомнил пару ключевых фильтров - и поиск занимает секунды вместо минут листания.

Самый недооценённый инструмент Git - pickaxe (буквально «кирка»). Это поиск по тому, что появилось или исчезло в коммитах.

git log -S "<строка>" - найти коммиты, после которых количество вхождений строки в любом файле изменилось. Иначе говоря - коммиты, которые добавили или удалили эту строку.

git log -S "calculateTotal"

# покажет коммиты, в которых количество "calculateTotal"

# в файлах поменялось

Это не просто grep по diff'ам. -S точно знает, что строка «появилась» или «пропала», и игнорирует случаи, когда строка просто переехала из одной части файла в другую (там количество вхождений не изменилось).

Типичный сценарий - нашёл странную константу или функцию, хочешь понять, кто её добавил:

git log -S "MAGIC_TIMEOUT = 8675"

# один или несколько коммитов

# дальше git show <sha> - и видишь полный контекст

-G "<regex>" - похоже, но через регулярное выражение и без хитрости с подсчётом вхождений. Просто «коммиты, у которых diff матчит regex». Чаще нужен -S (он точнее), -G - если ищешь по шаблону.

git log -G "TODO\(.*\)"

Полезный довесок - флаг -p показывает diff:

git log -S "calculateTotal" -p

# увидишь, в каких коммитах добавилось/убралось,

# с полным контекстом каждой правки

git log -S уверенно находит «откуда взялась эта функция» за одну команду в репозиториях с десятком тысяч коммитов. Знание этого экономит часы.

git blame <file> показывает для каждой строки файла: SHA последнего коммита, который её тронул, автора и дату.

git blame src/auth.py

# a1b2c3d (Dmitry 2026-05-15 12:34:11 +0300  1) def login(user):

# a1b2c3d (Dmitry 2026-05-15 12:34:11 +0300  2)     check(user)

# e4f5a6b (Olya   2026-04-12 09:11:23 +0300  3)     log_attempt(user)

# a1b2c3d (Dmitry 2026-05-15 12:34:11 +0300  4)     return token

Используется на вопрос «кто и в каком коммите написал эту строку». Имя вводящее в заблуждение - blame не «обвиняет», просто атрибутирует.

Полезные опции:

git blame -L 10,30 file.py          # только строки 10-30

git blame -L "/def login/,/return/" # от регулярки до регулярки

git blame -w                         # игнорировать whitespace в правках

git blame -C -C -C                   # отслеживать copy-paste между файлами

git blame --since="3 months ago"     # только недавние правки

Важная тонкость: blame показывает последний коммит, тронувший строку. Если коммит просто переформатировал файл (например, прогнали через prettier), blame покажет тот форматирующий коммит для каждой строки - и оригинальная история теряется.

Решение - флаг -w (игнорировать whitespace) и опция --ignore-rev:

git blame --ignore-rev <sha-форматера> file.py

Или в проектах есть файл .git-blame-ignore-revs со списком «коммитов-форматеров», которые надо проигнорировать. Настроить Git, чтобы он его подхватывал:

git config --global blame.ignoreRevsFile .git-blame-ignore-revs

GitHub автоматически уважает .git-blame-ignore-revs в корне репозитория - в blame через веб эти коммиты пропускаются.

См. blame.

Самый мощный инструмент расследования багов. Сценарий: «раньше работало, теперь нет, в истории сотни коммитов». git bisect за log(N) шагов находит первый коммит, где сломалось.

git bisect start

git bisect bad                # текущий - сломанный

git bisect good v1.4          # известный рабочий - это v1.4 (или SHA)

Git переключит репозиторий на коммит посередине между good и bad. Ты проверяешь: работает? Не работает?

# ... протестировал, баг есть ...

git bisect bad

# ... протестировал, бага нет ...

git bisect good

Git делит интервал пополам и переключает дальше. За log2(N) шагов сходится к одному коммиту: «вот этот коммит превратил good в bad».

git bisect bad

# a1b2c3d is the first bad commit

# commit a1b2c3d

# Author: ...

# Date:   ...

#

#     refactor: extract calculator class

По окончании - git bisect reset, который вернёт HEAD на исходную ветку.

Полезные команды во время bisect:

git bisect log              # лог bisect-сессии

git bisect visualize        # показать оставшийся интервал

git bisect skip             # пропустить коммит, который не

                            # удаётся проверить (сборка не идёт)

git bisect reset            # выйти из bisect, вернуть HEAD

Bisect работает не только для «сломалось» vs «работает». Можно использовать любые два слова через --term-good/--term-bad, когда «good» звучит неуместно (например, ищешь когда фича появилась):

git bisect start --term-old=missing --term-new=present

git bisect present

git bisect missing v1.0

Если у тебя есть скрипт, который проверяет, сломан ли проект на текущем коммите, bisect делает всю работу сам.

git bisect start

git bisect bad

git bisect good v1.4

git bisect run ./check.sh

Git будет переключать коммиты и запускать ./check.sh на каждом. Контракт скрипта:

• exit 0 → коммит good (тест прошёл)
• exit 1..124, 126..127 → коммит bad (тест упал)
• exit 125 → пропустить коммит (как git bisect skip)

Все остальные коды - фатальная ошибка, bisect остановится.

Пример с pytest:

git bisect run pytest tests/test_login.py::test_password_reset

Pytest возвращает 0 при успехе, 1 при провале - bisect это понимает естественно. Через 5-10 минут получишь точный SHA коммита-источника.

Когда полезно скрипт писать самому:

# check.sh

#!/usr/bin/env bash

set -e

# сборка может сломаться сама по себе - пропускаем

make build || exit 125

# запускаем конкретный сценарий

./run-app &

APP_PID=$!

sleep 2

RESULT=$(curl -s http://localhost:8000/api/health)

kill $APP_PID

if [[ "$RESULT" == "ok" ]]; then

    exit 0

else

    exit 1

fi

Это и есть «автоматическая регрессия за 10 минут на репозитории с десятком тысяч коммитов». Реальный пример: ядро Linux использует bisect для нахождения регрессий, и в среднем хватает 15-20 шагов на историю в сотни тысяч коммитов.

Bisect работает на предположении, что свойство монотонно: если коммит good - все коммиты до него тоже good, если bad - все после bad. На практике это не всегда так.

Промежуточные коммиты не собираются. Если в истории есть коммиты, которые не компилируются (а такие случаются - за это ругают и любят атомарность из главы 7), bisect не сможет их протестировать. Решение - git bisect skip в ручном режиме или exit code 125 в автоматическом.

Перемежающаяся регрессия. Если баг возник, исчез, возник снова, bisect найдёт какую-то границу, но не первую. В длинной истории с шумом bisect даёт ложноположительный. Лечится точностью теста: чем меньше тест зависит от других коммитов, тем чище bisect.

Зависимость от внешнего окружения. Если коммит работает только с определённой версией зависимости, а ты bisect'ишь без переустановки зависимостей - тест может падать не из-за коммита, а из-за окружения. Включи переустановку в скрипт.

Test-driven regression. Иногда регрессию вообще не видно на тестах того времени - её добавили позже. Тогда bisect бесполезен; нужно вручную смотреть git log -S, искать по авторам, искать в blame. Bisect только для «было - нет, стало - есть» детерминированных случаев.

В целом bisect - это полпроцента ситуаций, где он применим, и в этих полпроцентах он экономит часы. Если применим, его применять надо обязательно.

Самые сильные сценарии расследования - это связки. Парочка примеров.

«Кто добавил эту константу - может, помнит зачем».

# 1. Найти коммит, где появилась константа

git log -S "MAX_RETRIES = 7" --oneline

# a1b2c3d: refactor: tune retry policy

# 2. Посмотреть, что вообще в этом коммите происходило

git show a1b2c3d

# 3. Если автор всё ещё в команде - спросить

«В этом файле сейчас бага - когда он сломался?».

# 1. Найти строку в blame

git blame src/api.py | grep "raise ApiError"

# 2. Посмотреть коммит, который её добавил

git show <sha>

# 3. Если это и есть источник - готово.

#    Иначе - bisect или log -S по этой строке.

«Кто-то закоммитил console.log в продакшен».

git log -S "console.log" --all --since="1 month ago" -p

Покажет все коммиты за последний месяц, в которых появилось или исчезло console.log - даже если они уже мерджились, ребейзились, и т.д.

«В архивной ветке был полезный кусок кода, не помню где».

git log --all -S "def calculate_discount" -p

--all ищет по всем веткам и tag'ам, не только по текущей. Полезно, когда работа была сделана в боковой ветке, не смерженной в main.

Эти связки полезно держать в шпаргалке. Чаще всего нужны они три: log -S, blame, bisect. Остальные - по случаю.