5 git-команд, которые стоит запустить перед чтением чужого кода

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

Это перевод статьи Грега Пеховски, консультанта по аудиту кодовых баз. Его подход — диагностика проекта через историю коммитов, прежде чем читать хоть одну строку кода.

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

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

20 самых часто изменяемых файлов за последний год. Файл на первом месте — почти всегда тот, про который предупреждают: «А, этот файл. Его все боятся трогать».

Высокий churn (частота изменений) сам по себе не проблема — иногда это просто активная разработка. Но высокий churn у файла, за который никто не хочет отвечать — самый чёткий сигнал «тормозящего» кода. Это файл, где каждое изменение — патч на патч, а последствия мелкой правки непредсказуемы.

Исследование Microsoft Research 2005 года показало, что метрики на основе churn предсказывают дефекты надёжнее, чем метрики сложности кода. Автор рекомендует взять топ-5 файлов из этого списка и сверить их со списком баг-хотспотов (команда ниже). Файл, который одновременно high-churn и high-bug — главный риск проекта.

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

			git shortlog -sn --no-merges
		

Все контрибьюторы, отсортированные по числу коммитов. Если один человек — автор 60% и более коммитов, это bus factor. Если он ушёл полгода назад — это кризис.

Проверьте, кто активен за последние полгода:

			git shortlog -sn --no-merges --since="6 months ago"
		

Если топ-контрибьютор за всё время не появляется в полугодовом окне — это красный флаг, который стоит сразу обсудить с командой.

Смотрите и на «хвост» списка: 30 контрибьюторов всего, но только трое активны за последний год. Люди, которые строили систему — не те, кто её поддерживает.

Нюанс: если команда использует squash-merge, команда покажет того, кто мержил, а не того, кто писал код. Уточните стратегию мержа, прежде чем делать выводы.

Где скапливаются баги

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

Та же структура, что и команда churn, но отфильтрованная по коммитам с ключевыми словами багов. Сравните этот список с churn-хотспотами: файлы, попавшие в оба списка — самый рискованный код. Они постоянно ломаются и постоянно патчатся, но никогда не чинятся по-настоящему.

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

Проект растёт или умирает

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

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

• Ровный ритм — здоровый проект
• Резкое падение вдвое за месяц — обычно кто-то ушёл
• Нисходящая кривая за 6-12 месяцев — команда теряет темп
• Всплески с тишиной между ними — пакетные релизы вместо непрерывной поставки

Однажды я показал CTO график коммитов его команды. Он сказал: «Это когда мы потеряли второго senior-инженера». Раньше он не связывал эти события. Это данные о команде, не о коде.

Грег ПеховскиАвтор, консультант по аудиту кодовых баз

Как часто команда тушит пожары

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

Частота revert и hotfix. Несколько за год — норма. Откаты каждые пару недель — команда не доверяет своему деплой-процессу. Это симптом глубже: ненадёжные тесты, отсутствие staging или пайплайн, в котором откат сложнее, чем должен быть.

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

Пять команд, пара минут. Они не расскажут всё, но покажут, какой код читать первым и что искать. Разница между методичным погружением в кодовую базу и бесцельным блужданием по файлам.

Оригинал: Git commands I run before reading any code, Грег Пеховски.