Git-трюки для профи: 5 команд, которые спасут часы дебага

1. git bisect - детектив для поиска бага

Представь: ты работаешь над проектом месяц, и вдруг замечаешь, что неделю назад сломался важный функционал. Пересматривать сотни коммитов вручную - ад. Git bisect делает это за тебя, используя бинарный поиск.

Как работает: Ты указываешь «плохой» коммит (где баг есть) и «хороший» (где его нет). Git последовательно переключает тебя на промежуточные коммиты, и ты каждое состояние помечаешь как good или bad. Через ~10 шагов (даже для 1000 коммитов) найдётся виновник.

Пример:
git bisect start
git bisect bad # текущий коммит с багом
git bisect good abc123 # коммит, где всё работало
# Git переключает на середину истории. Тестируешь.
git bisect good # если бага нет
# или
git bisect bad # если баг есть
# Повторяешь, пока не увидишь:
# "abc456 is the first bad commit"
git bisect reset # вернуться к исходному состоянию

Зачем: Вместо перебора 500 коммитов вручную - 9-10 итераций. Идеально, когда баг плавающий или не очевиден по логам.

2. git stash --include-untracked - спрячь всё, даже новый код

Обычный git stash прячет только отслеживаемые файлы. Но если ты начал писать новый модуль и не успел его добавить в индексацию, при переключении на другую ветку новые файлы «выпадут» и будут мешать. Флаг --include-untracked (сокращённо -u) решает проблему.

Пример: У тебя есть неотслеживаемый файл new_feature.py и изменённый main.py. Нужно срочно пофиксить баг в другой ветке.


git stash -u # сохраняет и изменённые, и новые файлы
git checkout hotfix
# ... фикс бага ...
git checkout main
git stash pop # восстанавливает всё: new_feature.py и изменения в main.py

Зачем: Избегаешь ситуации, когда при смене ветки новые файлы «зависают» и мешают коммитить или пуллить. Особенно полезно в проектах с автоматическими линтерами и тестами, которые могут упасть из-за мусора.

3. git log --all --oneline --graph --decorate - карта твоей истории

Когда в проекте работают 5+ разработчиков, история коммитов превращается в паутину из слияний. Обычный git log показывает список, но не даёт понять, где ветвились, где делали merge и rebase.

Пример команды:
git log --all --oneline --graph --decorate --since="2 weeks ago"

Ты увидишь ASCII-граф, где строки соединяются линиями. Каждая ветка - своя «дорога». --decorate подписывает имена веток и тегов. --since - фильтр по дате, чтобы не засорять вывод всей историей.

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

Совет: Сделай алиас в ~/.gitconfig:
[alias]
tree = log --all --oneline --graph --decorate

4. git commit --fixup - исправляй коммиты без стыда

Ты сделал коммит, а через час заметил опечатку в коде или забыл добавить файл. Вместо нового коммита с сообщением "fix typo" (который засоряет историю) используй --fixup. Он создаёт коммит, помеченный как исправление к определённому хешу.

Пример: Ты закоммитил abc123, но забыл импорт. Вместо нового сообщения:


git add forgotten_import.py
git commit --fixup abc123
# Создаётся коммит с сообщением "fixup! Название исходного коммита"

Потом, когда захочешь прибраться в истории, выполни git rebase -i --autosquash HEAD~5. Git автоматически подставит fixup-коммиты к их «родителям» и склеит их в один, удалив лишние сообщения.

Зачем: История остаётся чистой - без кучи "fix", "typo", "oops". При code review коллеги не путаются в бесконечных исправлениях. Помогает соблюдать политику «один коммит - одна логическая единица работы».

5. git blame -w - кто на самом деле написал эту строку?

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

Как исправить: Флаг -w (ignore whitespace) игнорирует изменения, которые касаются только пробелов, табуляции и пустых строк.


git blame -w src/app.js

Git сравнит строки, не учитывая пробельные символы. Если строка изменилась только по whitespace, он покажет автора, который написал её впервые (до рефакторинга).

Зачем: Когда нужно найти, кто добавил конкретную логику, а не кто форматировал код. Экономит часы выяснений: «Я же не трогал эту функцию, это formatting-коммит!». Особенно актуально в командах, где есть автоформатеры (Prettier, Black).