Git-логи без боли: как связать grep, less и tail

Когда в релизе что-то сломалось, проблема редко решается одной командой git log. В истории Git нужно найти коммит, в выводе — отфильтровать сотни строк, а в текущем файле приложения — следить за новыми ошибками. Для этого достаточно связки grep, less и tail, но у каждого инструмента своя задача. Ниже — практический сценарий для Git 2.46 и новее в Linux и macOS; команды Unix отличаются от вариантов для PowerShell.

Сначала разделите два вида логов

История Git — это записи о коммитах, авторах, ветках и изменениях. Её показывает git log. Лог приложения — текстовый файл, куда сервер, веб-приложение или фоновый процесс пишет события во время работы. Его обычно читают через less, grep и tail.

Смешивать эти источники опасно. Поиск слова timeout в истории Git не покажет, что происходило с сервером в 14:35. И наоборот, текущий app.log не ответит, какой коммит добавил проблемный вызов.

Git помогает найти изменение, а tail — момент, когда система столкнулась с ним в работе. Между этими событиями обычно и находится причина инцидента.

Сноска. Пайп (|) — передача вывода одной команды на стандартный ввод другой. Например, в git log --oneline | grep auth результат Git сразу становится входом для grep.

Что делает каждая команда

Ищите коммит средствами Git, а не только grep

Самый короткий журнал для первичного поиска:

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

--oneline оставляет по одной строке на коммит, --graph показывает ветвление, а --all включает локальные ссылки на все ветки. Для поиска по тексту сообщения используйте встроенный фильтр:

git log --all --oneline --regexp-ignore-case --grep='timeout'

Так вы ищете именно в сообщениях коммитов. Команда не ищет слово внутри содержимого файлов. Если нужно понять, когда появилась или исчезла конкретная строка, используйте два других режима:

git log --all -S'connect_timeout' --oneline
git log --all -G'connect_.*timeout' --oneline

-S ищет изменение количества точных вхождений строки, а -G — изменения, соответствующие регулярному выражению в diff. Для большого репозитория добавляйте ограничение по пути:

git log --all --oneline -- app/config.py

Фильтрация через grep тоже полезна, когда вы уже сформировали удобный видимый отчёт:

git log --all --format='%h %ad %an %s' --date=short | grep -i 'payment'

Но у такого способа есть ограничение: grep видит только напечатанный текст. Он не знает, где заканчивается коммит, какая строка относится к автору и какой файл был изменён. Для анализа истории сначала применяйте возможности Git, а grep оставляйте для финального текстового фильтра.

Читайте длинный diff через less

Команда git show или git log -p может вывести тысячи строк. Отправьте результат в просмотрщик:

git log -p -- app/config.py | less
git show --stat --oneline a1b2c3d | less

Внутри less работают привычные клавиши: /timeout ищет вперёд, ?timeout — назад, n переходит к следующему совпадению, N — к предыдущему, q закрывает просмотр. В режиме diff цвет и длинные строки могут мешать. Для горизонтальной прокрутки используйте -S:

git log -p -- app/config.py | less -S

Смысл -S — не переносить длинные строки, а обрезать их по ширине окна и дать прокручивать вправо. Это удобно для JSON, SQL и длинных путей, но часть текста окажется за пределами экрана.

Если Git сам открыл pager, не нужно запускать второй less. Признак двойной обёртки — неожиданные переходы или необходимость несколько раз нажимать q. Для разовой команды можно отключить встроенный просмотрщик:

git --no-pager log --oneline --all

Следите за текущим логом через tail

Чтобы быстро посмотреть последние 100 строк файла:

tail -n 100 /var/log/myapp/app.log

Чтобы не перезапускать команду после каждой записи, добавьте режим наблюдения:

tail -n 100 -f /var/log/myapp/app.log

Теперь новые строки будут появляться в терминале по мере записи. Остановить просмотр можно клавишами Ctrl+C. Для параллельного поиска ошибок удобнее передать вывод в grep:

tail -n 200 -f /var/log/myapp/app.log | grep --line-buffered -i -E 'error|exception|timeout'

Параметр --line-buffered относится к GNU grep и нужен, чтобы совпадения не накапливались в буфере перед выводом. На macOS он может отсутствовать в системной версии grep. В этом случае проверьте grep --help или установите совместимую версию отдельно, не подменяя системные команды вслепую.

Если приложение создаёт новый файл после ротации логов, обычный -f может продолжить следить за прежним дескриптором. В GNU coreutils и в стандартном tail macOS для такого сценария используется:

tail -n 100 -F /var/log/myapp/app.log

Опция -F повторно открывает файл, если он был переименован или создан заново. На сервере всё равно проверьте справку конкретной ОС: поведение и набор ключей системных утилит могут различаться.

Свяжите историю изменения и рабочую ошибку

Практический поиск обычно идёт в три этапа:

1. Найдите подозрительный коммит. Начните с git log --all --oneline --grep='...' или с -S, если известна строка кода. Проверьте результат через git show COMMIT: должен открыться diff именно нужного файла.
2. Посмотрите временной диапазон в файле. Запустите tail -n 500 app.log | less, а затем ищите через / идентификатор запроса, код ответа или текст исключения. Убедитесь, что найденная запись относится к нужному окружению.
3. Сопоставьте признаки. Используйте одинаковые часы, идентификатор релиза и название компонента. Если ошибка появилась после деплоя, это ещё не доказывает, что виноват последний коммит: фоновые задачи и конфигурация могли измениться отдельно.

Проверка результата здесь не сводится к строке «команда отработала». Хороший результат — это конкретный коммит, участок diff и запись в логе с понятным временем или request ID.

Что ломается чаще всего

grep ничего не находит

Проверьте регистр, кодировку и то, что слово действительно есть в выводе. Для первого теста используйте grep -i, а затем уберите его, если регистр важен. В истории Git сначала убедитесь, что grep получает данные: выполните команду без пайпа и проверьте первые строки.

tail показывает старые записи, но не новые

Файл мог быть ротирован, заменён или перестал пополняться. Проверьте путь, время изменения файла и попробуйте tail -F. Если приложение пишет в контейнерный stdout, нужного файла на хосте может не быть вовсе: журнал тогда нужно искать средствами платформы запуска.

В выводе потерялся контекст

Пайп вроде git log -p | grep timeout оставит только совпавшие строки и удалит заголовок коммита. Для diff используйте grep -C 3, чтобы сохранить по три строки вокруг совпадения, либо сначала откройте полный результат в less и ищите внутри него.

Команда зависла

Чаще всего это не зависание, а открытый less или режим tail -f. Нажмите q для выхода из less и Ctrl+C для остановки tail. Если команда запущена в удалённой сессии, не оставляйте бесконечное наблюдение без необходимости.

Когда что выбирать

Используйте git log --grep, когда вопрос звучит как «какой коммит назывался так». Берите -S или -G, когда нужно найти изменение в коде. Открывайте less, если ответ длинный и его нужно читать с контекстом. Запускайте tail -f или tail -F, если событие происходит прямо сейчас и важно увидеть новые строки без повторного запуска команды.

Не пытайтесь превращать связку в систему хранения логов. Она подходит для разового расследования на рабочей машине или сервере, но не заменяет централизованный сбор, поиск по полям и контроль доступа. Формат логов, ротация и срок хранения — отдельная тема.

Что делать дальше

Соберите короткий диагностический набор для своего проекта: команда поиска по истории, команда просмотра diff и команда наблюдения за логом релиза. Затем добавьте в записи приложения время в едином часовом поясе, имя сервиса и идентификатор запроса. На следующем инциденте измеряйте не количество найденных строк, а время от первой ошибки до связанного коммита и подтверждённого исправления.