Пять git-команд для диагностики кодовой базы

Знаешь, что меня всегда удивляет? Мы приходим в новый проект и первым делом открываем файлы. Читаем код строчка за строчкой, пытаемся понять логику, запоминаем названия функций. Но код — это следствие. А история того, как этот код создавался, — вот где настоящая информация.

Недавно я наткнулся на статью, где автор рассказывает о пяти git-командах, которые он запускает перед тем, как вообще тронуть код. Пять минут в терминале — и ты понимаешь, где проблемы, кто их создал и стоит ли вообще лезть в этот файл руками.

Звучит как магия? Давайте разберёмся.

Зачем смотреть в историю

Когда ты открываешь незнакомую кодовую базу, у тебя есть два пути. Первый — читать всё подряд и надеяться, что поймёшь контекст. Второй — сначала изучить «диагностическую картину» проекта: кто его писал, где постоянные баги, как команда работает с релизом.

Git хранит всё это. Каждый коммит — это маленькая история: что изменилось, кто менял, когда. И если уметь эти истории читать, ты получаешь огромное преимущество.

Автор статьи — Марчин Пёчовски (Marcin Piechowski) — называет это «первым часом аудита кодовой базы». И знаешь что? Это работает лучше, чем ты думаешь.

Какие файлы пугают всех

Самая полезная команда — та, что показывает файлы с самой высокой «текучкой»:

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

Эта команда выводит топ-20 файлов, которые менялись чаще всего за последний год. И поверь, файл на первой строчке — это всегда интересно.

Автор пишет, что верхняя строчка — это обычно тот файл, про который люди говорят: «О, да. Этот файл. Все боятся его трогать».

Высокая текучка не всегда означает, что файл плохой. Иногда это просто активная разработка. Но высокая текучка + никто не хочет этот файл поддерживать — это самый верный сигнал кодового долга.

Есть даже исследование Microsoft Research 2005 года, которое показало, что метрики текучки предсказывают баги лучше, чем метрики сложности кода. То есть файл, который часто меняется, скорее всего, будет ломаться.

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

Кто написал этот код

Следующая команда — про авторов:

git shortlog -sn --no-merges

Она показывает всех контрибьюторов, отсортированных по количеству коммитов. Простая и мощная штука.

Если один человек сделал 60% коммитов — это твой «фактор автобуса». Если он ушёл полгода назад — у тебя проблемы. Но ещё интереснее посмотреть на «хвост». Тридцать человек в проекте, но только трое активны за последний год. Это значит, что систему писали одни люди, а поддерживают другие. И они, скорее всего, не до конца понимают, как это работает.

Есть одна оговорка: если команда использует squash-merge (когда каждый PR сливается в один коммит), эта команда покажет того, кто мержил, а не того, кто писал код. Стоит уточнить стратегию мержей перед выводами.

Где прячутся баги

Команда для поиска проблемных мест:

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

Она ищет коммиты с ключевыми словами «fix», «bug», «broken» и показывает, какие файлы в этих коммитах менялись. По сути — карта багов.

Сравни этот список с топом текучки. Файлы, которые попадают в оба списка — это твоя зона повышенного риска. Там постоянно что-то ломается и постоянно патчат, но по-настоящему не чинят.

Работает это, конечно, зависит от культуры коммитов. Если команда пишет «update stuff» в каждом коммите — толку не будет. Но даже примерная карта плотности багов лучше, чем никакой.

Проект жив или умирает

Хочешь понять, ускоряется команда или теряет импульс? Вот команда:

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

Она показывает количество коммитов по месяцам за всю историю репозитория.

Ровный ритм — это здоровье. Падение активности в два раза за месяц — обычно значит, что кто-то ушёл. Устойчивый спад за 6-12 месяцев — команда теряет импульс. Периодические всплески и тишина между ними — значит, работают релизами, а не непрерывно.

Автор рассказывает случай: он показал CTO график активности, и тот сказал: «О, это когда мы потеряли второго старшего инженера». До этого момента он не связывал график с событиями в команде.

Это, кстати, важно понимать: данные git — это данные о команде, а не о коде. И иногда они рассказывают вещи, которых в коде не видно.

Как часто тушат пожары

Последняя команда — про горячие исправления:

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

Она ищет коммиты с ключевыми словами «revert», «hotfix», «emergency», «rollback». Несколько таких за год — нормально. Если они каждые пару недель — это сигнал: команда не доверяет своему процессу деплоя.

Автор говорит, что это признак более глубоких проблем: ненадёжные тесты, отсутствие стейджа (тестовой среды), или пайплайн деплоя, который делает откат сложнее, чем должен быть.

Ноль результатов — тоже сигнал. Либо команда стабильная, либо никто не пишет описательные коммиты. Кризисные паттерны легко читаются: либо они есть, либо нет.

Что в итоге

Вот эти пять команд занимают пару минут. Они не расскажут всё. Но ты будешь знать, какой код читать первым и что искать. Это разница между «первый день читаю кодовую базу методично» и «первый день блуждаю без цели».

ПЯТЬ КОМАНД ДЛЯ ДИАГНОСТИКИ
─────────────────────────────
1. Топ файлов по текучке    → «Где риск?»
2. shortlog                 → «Кто написал?»
3. Поиск багов              → «Где ломается?»
4. Активность по месяцам    → «Жив ли проект?»
5. revert/hotfix            → «Тушат ли пожары?»

         ▼
    2 минуты в терминале
    = понимание проекта

Лично мне эта идея зашла. Обычно я тоже сначала смотрю на структуру проекта, но делаю это руками — открываю файлы, читаю, пытаюсь понять. А тут можно получить примерно ту же информацию за пару минут и уже потом идти в код осознанно.

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

Попробуй в следующий раз, когда придёшь в новый проект. Запусти эти команды и посмотри, что они тебе расскажут. Удивишься, сколько всего можно узнать, не открыв ни одного файла.

Ссылки

• Оригинальная статья: The Git Commands I Run Before Reading Any Code — статья Марчина Пёчовски о пяти git-командах для диагностики кодовой базы.
• Исследование Microsoft Research о связи текучки и дефектов (2005) — исследование, показывающее, что текучка кода лучше предсказывает баги, чем сложность кода.