Как обнаружить ошибку с помощью git bisect

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

Иногда мы долго-долго работаем над проектами. Мы могли бы создать идеальный выпуск 1.0, затем опубликовать его и начать работу над исправлением ошибок, затем мы получаем запросы на добавление функций и работаем над улучшением приложения.

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

Что-то работает не так, как ожидалось, хотя вы недавно действительно не меняли эту часть кода.

Или, может быть, вы так много раз касались файла или функции, что не можете вспомнить, какое изменение могло вызвать проблему, о которой вам сообщили.

В любом случае первое, что нужно сделать, - этоопределить, где ошибка.

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

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

я используюGitHub Desktop, замечательный клиент Git отGitHub. Он отлично подходит для повседневного использования, но не позволяет мне проверить ни одной фиксации. Некоторые другие клиенты это делают, но вы можете использоватькомандная строка.

Пробег

git checkout <COMMIT_SHA>

кудаэто фиксация, к которой вы хотите откатиться. Это будет выглядеть примерно так5a06d3ca5e7adb6e67.

Если проблема не исчезла, попробуйте сделать то же самое с другой фиксацией, сделанной накануне, и так далее, пока не найдете фиксацию, в которой работает код.

Теперь вам нужно применитьразделяй и властвуйпринципа, и выберите коммит посередине последнего, который вы пробовали (и не сработали), и того, который работает.

Повторите процесс и сокращайте вдвое каждый раз интервал фиксации, пока не определите фиксацию, которая привела к проблеме.

Это настолько распространенная и полезная вещь, что Git представилbisectкоманда для автоматизации этого процесса.

Начните с вашего последнего коммита. Использоватьgit checkout your-branch-name, Напримерgit checkout masterесли вы уже проверяли более старую фиксацию.

Затем запустите:

git bisect start

Пока ничего не произошло. Вам нужно сообщить GitПлохоссылка на фиксацию, где код не работает:

git bisect bad HEAD

ихорошийкоммит, где работал код:

git bisect good 7f4d976e7540e28c6b0

Git запускает процесс:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25

Видите ли, у вас есть 6 коммитов между HEAD и коммитом, который я назвал хорошим. Git сообщает мне, что у меня есть еще 2 шага, пока мы не найдем проблемную фиксацию.

Я иду и тестирую код, затем сообщаю Git результат:git bisect badили жеgit bisect goodв зависимости от успеха.

Повторяйте, пока не найдете плохую фиксацию, а затем запуститеgit bisect resetчтобы вернуться к фиксации HEAD.

Git проведет вас в этой операции деления пополам. Вы вводите SHA коммита


Дополнительные руководства по git: