Сократите свои коммиты

Сегодня я заметил, что один из стилей пользовательского компонента перепутался. Компонент состоит из фрагмента текста между двумя значками. Раньше между иконками и текстом было достаточно места, но теперь его нет.

Сначала я заподозрил, что класс был изменен. Возможно, у него были какие-то отступы, а теперь нет, но быстрая проверка в Chrome Developer Tools не показала таких отступов в производственной версии (которая все еще выглядит правильно).

Стало очевидно, что я сломал его где-то на прошлой неделе или около того. Я часто совершаю коммиты, поэтому просмотр каждого коммита был бы трудоемким и трудоемким. Если бы только был способ сузить коммиты и пройти их логически и методично.

Что ж, с git-bisect есть!

Git-Bisect спешит на помощь

Что такое git-bisect? Это умная и редко используемая утилита, которая позволит вам выполнить серию коммитов, сократив коммиты пополам, протестировав приложение, а затем повторив процесс.

Вот как это работает и как я это использовал.

Во-первых, найдите коммит где-то в прошлом, где вы точно знаете, что код работал. Скопируйте хэш этого коммита. Это будет вашей отправной точкой. Другой конец биссектрисы — это ваш коммит HEAD, который, как вы знаете, сломан.

Мне пришлось просмотреть свой журнал git, чтобы найти коммит, который изначально включал мой код. Я запустил `git log — oneline | head -25`, чтобы увидеть мои последние 25 коммитов. Я нашел тот, где я впервые реализовал код, который сейчас не работает, помня, что в то время он работал. Я обратил внимание на его хэш коммита, 2d8cf845.

Вооружившись этой информацией, я ввел следующие команды:

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

Вывод git-bisect говорит мне, что между этими двумя есть 6 ревизий или коммитов, и что мне нужно сделать 3 шага, чтобы найти виновника.

Запустите приложение

Теперь пришло время запустить приложение и посмотреть, существует ли проблема. Моя проблема визуальная, поэтому мне нужно собрать и запустить приложение и проверить вывод.

Это выглядит идеально. Вы можете увидеть расстояние между цифрой 1 и значками.

Итак, теперь я говорю git, что это хороший коммит.

Обратите внимание, что мне нужно было только сказать git-bisect, что этот коммит хорош. Затем он автоматически выбрал коммит между этим и моим плохим и проверил его для меня.

Я переделал и обновил приложение, и оно тоже было хорошим.

Этот тоже был хорош, поэтому я повторил приведенную выше команду.

Обратите внимание, что там написано, что осталось 0 ревизий и 0 шагов, так что лучше бы это была плохая версия, какой она и была.

С помощью git-bisect мне потребовалось всего три коммита, чтобы найти виновника.

Если бы это не был мой последний коммит, я бы пометил его как git bisect bad, а затем git продолжал бы сужать изменения, пока мы, наконец, не нашли бы нарушителя.

Найдите ошибку

Теперь, когда у меня есть коммит, я могу посмотреть на diff и узнать, что я мог сделать, чтобы сломать его.

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

Замена этой единственной удаленной строки решила мою проблему. Будучи хорошим командным игроком, я создал новую ветку с исправлениями и открыл запрос на вытягивание с этим однострочным изменением.

Заключение

Обнаружение неожиданной ошибки никогда не бывает хорошим чувством. Еще хуже, когда вы не можете вспомнить, как касались кода, который сломался. В моем случае я сделал изменение случайно, думая, что удаляю неиспользуемый импорт. Я был неправ.

К счастью, я смог использовать git-bisect, чтобы найти проблемный коммит, определить изменение, вызвавшее сбой, и внести исправление. Весь этот опыт, от начала до конца, занял у меня около получаса, включая время, которое я потратил на ведение записей и на написание этого объяснения.

Существует гораздо больше git-bisect, чем то, что я показал вам здесь. Если у вас есть модульные тесты, и вы пытаетесь найти коммит, который нарушил один или несколько из них, можно даже заставить git-bisect сделать большую часть работы за вас. Он может запустить ваши тесты и решить для себя, был ли коммит хорошим или плохим. Это продвинутая тема для другого дня.

Надеюсь, в следующий раз, когда вы окажетесь в похожей ситуации, вы вспомните эту статью и сами попробуете git-bisect.

👉 Хотите больше подобного контента, чтобы улучшить свои технические и профессиональные навыки?

Пожалуйста, ознакомьтесь с моей обширной коллекцией книг и курсов или подпишитесь на мою рассылку по адресу https://walkingriver.gumroad.com 📱