Поиск изменений в Git: git log, sed и git blame

Быстрые ссылки

• Using Git Log

• Using sed For Smarter Matching

• Maybe Use Git Blame Instead

Задача

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

Основные подходы — кратко

• Если нужно искать по всему репозиторию: git log с опцией поиска по патчу и диапазоном дат.
• Если нужно видеть конкретные строки в файле: использовать grep после git log или git grep по сторам/коммитам.
• Если известен файл: git blame — быстрый способ увидеть, кто и когда изменил каждую строку.

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

К сожалению, веб-интерфейсы (например, GitHub) не всегда предоставляют удобный поиск по диффам, поэтому приходится запускать команды локально.

Команда

git log

имеет множество опций. Полезные флаги для поиска по содержимому и времени:

• –after, –before — фильтрация по датам (можно указывать относительные значения: “6 week”, “1 month”).
• -S’string’ — поиск по изменениям, которые изменяют количество вхождений строки (так называемый pickaxe).
• -G’regex’ — поиск по регулярному выражению в диффах.
• –stat — краткая статистика файлов в каждом коммите.
• -p — показывать патчи (diff) для каждого коммита.

Пример: игнорировать коммиты старше 6 недель и новее 1 недели:

git log --after="6 week" --before="1 week"

Если нужно только узнать, в каких коммитах появляется искомая строка:

git log --after="6 week" -S'Dictionary' --stat

Чтобы увидеть файлы и патчи, добавьте -p. Но учтите, что вывод может быть огромным для больших запросов:

git log --after="6 week" -S'Dictionary' --stat -p | cat

Важно: встроенный интерактивный постраничный просмотр Git (pager) не всем удобен. Вместо этого можно использовать поиск по выводу (нажать “/“ в pager) или направить вывод в файл для последующего анализа:

> log.txt

Улучшенный поиск: grep + sed

Если нужно вывести и коммит-заголовки, и конкретные строки с совпадениями, сочетание git log с grep потеряет заголовки, а sed поможет их сохранить и отфильтровать.

Базовый (дублирует шаблон дважды):

git log --after="6 week" -S'Dictionary' --stat -p | grep 'Dictionary'

Проблема: теряются заголовки коммитов. Решение — сохранить шаблон в переменной и обработать поток sed:

SEARCH=Dictionary && git log --after="6 week" -S$SEARCH --stat -p | sed -n "/commit/,/diff/p; /$SEARCH/p"

Разбор команды:

• SEARCH=Dictionary — переменная для удобства и предотвращения дублирования.
• git log –stat -p — полный вывод коммитов с патчами.
• sed -n “/commit/,/diff/p; /$SEARCH/p” — печатает блоки от строки “commit” до строки “diff” (это включает заголовок коммита и –stat), затем печатает строки с совпадением.

Результат — читаемый список коммитов с заголовками и только теми строками, где есть совпадение.

Советы по регулярным выражениям и экранированию:

• Если в поиске специальные символы, используйте single quotes ‘…’ или экранируйте их в переменной.
• Для более гибкого поиска по контексту используйте -C в grep (контекст строк) или опцию -U в sed/awk для расширенной обработки.

Когда использовать -S vs -G

• -S”строка” ищет изменения, которые изменяют количество вхождений точной подстроки (полезно, если вы ищете добавление/удаление конкретной строки).
• -G”regex” ищет изменения, где diff соответствует регулярному выражению (полезно для поиска по шаблонам).

Пример с -G:

git log -G"TODO|FIXME" --patch

Возможно, лучше git blame

Если вы знаете файл, быстрее воспользоваться git blame — он аннотирует каждую строку файлы автором и коммитом, в котором строка была внесена.

git blame path/to/file.ext

На GitHub есть удобная GUI-кнопка «Blame» при просмотре файла.

Обратите внимание: git blame показывает последний коммит, изменивший строку; если строка была впоследствии перемещена или отформатирована, результат может указывать на более поздний коммит, не на первоначальное добавление логики.

Когда один метод не работает (контрпримеры)

• Файлы были рефакторены (переименованы/перемещены): git blame может показать коммит переименования, а не изначальное добавление. Решение: использовать git log –follow для истории файла.
• Коммиты объединены (squash) или переписана история (rebase) на удалённом репозитории: это меняет SHA и усложняет поиск — ориентируйтесь по содержимому и сообщениям коммитов.
• Поиск по очень общим словам выдаёт шум: используйте более точные шаблоны или ограничьте диапазон дат/путей.

Альтернативы и дополнения

• git grep — быстрый поиск по текущим версиям файлов в рабочем каталоге и по историческим данным с опцией –cached / –revs.
• git bisect — если вы знаете, что баг появился между двумя точками, автоматизируйте двоичный поиск коммита.
• Использовать IDE или специализированные инструменты (Sourcegraph, OpenGrok) для индексированного поиска в больших кодовых базах.

Мини-методология (пошагово)

1. Оцените объём поиска: весь репозиторий или конкретный файл.
2. Если файл известен: начать с git blame + git log –follow.
3. Если файл неизвестен: запустите git log с -S или -G и сузьте по датам/путям.
4. Направьте вывод в sed/grep для читаемости и сохраните результат в файл для дальнейшего анализа.
5. При необходимости используйте git bisect для проверки регрессий.

Чеклист ролей

• Разработчик:
  • Сузил диапазон дат и путей.
  • Использовал -S или -G по потребности.
  • Сравнил результат с git blame.
• Тимлид/ревьювер:
  • Проверил авторов и сообщения коммитов.
  • Уточнил контекст в связных коммитах.
• Инженер релизов:
  • Убедился, что rebase/squash не скрыли авторство.
  • При необходимости использовал git bisect.

Snippet — короткая шпаргалка команд

# Быстрый поиск по репозиторию (точная подстрока)
git log -S'someText' --stat -p

# Поиск по регулярному выражению
git log -G"pattern" --patch

# Читаемый вывод с заголовками и совпадающими строками
SEARCH=someText && git log --after="6 week" -S$SEARCH --stat -p | sed -n "/commit/,/diff/p; /$SEARCH/p"

# Если известен файл
git blame --line-porcelain path/to/file | sed -n '1,5p'

# Проследить историю файла при переименовании
git log --follow -- path/to/file

Риски и примечания

Важно: поиск в больших репозиториях генерирует много данных — планируйте фильтрацию по датам, путям и используйте переменные для шаблонов. Если проект использует squash/rebase, привязка к SHA будет ненадёжной.

Краткое резюме

• Для поиска по всему репозиторию используйте git log с -S или -G и ограничивайте по дате/пути.
• Для удобного вывода комбинируйте git log с sed/grep.
• Если известен файл, начните с git blame и git log –follow.

Ключевые команды сохраните в виде шаблонов (переменные SEARCH), чтобы повторно использовать их без ошибок экранирования.

Критерии приёмки

• Вы можете найти хотя бы один коммит, содержащий добавление/удаление интересующей строки.
• Вы видите идентификатор коммита, автора и контекст изменений.
• При известном файле вы можете отследить первоначальное добавление через git blame + git log –follow.