Это команда git-bisect, которую можно запустить в провайдере бесплатного хостинга OnWorks, используя одну из наших многочисленных бесплатных онлайн-рабочих станций, таких как Ubuntu Online, Fedora Online, онлайн-эмулятор Windows или онлайн-эмулятор MAC OS.
ПРОГРАММА:
ИМЯ
git-bisect - Используйте двоичный поиск, чтобы найти фиксацию, которая привела к ошибке
СИНТАКСИС
мерзавец Bisect
ОПИСАНИЕ
Команда принимает различные подкоманды и разные параметры в зависимости от подкоманды:
git bisect start [--term- {old, good} = --term- {новый, плохой} = ]
[--no-checkout] [ [ ...]] [-] [ ...]
git bisect (плохо | новое) [ ]
git bisect (хороший | старый) [ ...]
git bisect terms [--term-good | --term-плохо]
git bisect skip [( | ) ...]
git bisect reset [ ]
git bisect визуализировать
git bisect replay
git пополам журнал
git bisect run ...
git bisect помощь
Эта команда использует алгоритм двоичного поиска, чтобы найти коммит в истории вашего проекта.
внесла ошибку. Вы используете его, сначала сообщая ему "плохой" коммит, который, как известно, содержит
ошибка и "хорошая" фиксация, известная до появления ошибки. Тогда git
bisect выбирает фиксацию между этими двумя конечными точками и спрашивает вас, будет ли выбранная фиксация
"хорошо" или "плохо". Он продолжает сужать диапазон, пока не найдет точную фиксацию.
это внесло изменение.
Фактически, git bisect можно использовать, чтобы найти коммит, который изменил любое собственность вашего
проект; например, фиксация, исправившая ошибку, или фиксация, вызвавшая
производительность для улучшения. Чтобы поддержать это более общее использование, термины "старый" и "новый" могут
можно использовать вместо «хорошего» и «плохого», или вы можете выбрать свои собственные термины. См. Раздел
«Альтернативные условия» ниже для получения дополнительной информации.
Базовый Bisect команды: начать, Плохо, хорошо
В качестве примера предположим, что вы пытаетесь найти фиксацию, которая нарушила функцию, которая была
известно, что он работает в версии v2.6.13-rc2 вашего проекта. Вы начинаете сеанс пополам как
следующим образом:
$ git начало пополам
$ git bisect bad # Текущая версия плохая
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 известен как хороший
После того, как вы указали хотя бы одну плохую и одну хорошую фиксацию, git bisect выбирает фиксацию
в середине этого диапазона истории, проверяет его и выводит что-то похожее на
следующие:
Деление пополам: после этого осталось проверить 675 ревизий (примерно 10 шагов)
Теперь вы должны скомпилировать извлеченную версию и протестировать ее. Если эта версия работает
правильно, введите
$ git bisect хорошо
Если эта версия не работает, введите
$ git bisect плохо
Тогда git bisect ответит чем-то вроде
Деление пополам: после этого осталось проверить 337 ревизий (примерно 9 шагов)
Продолжайте повторять процесс: скомпилируйте дерево, протестируйте его и, в зависимости от того, хорошее ли оно
или плохо запустить git bisect good или git bisect bad, чтобы запросить следующую фиксацию, которая требует
тестирование.
В конце концов, больше не останется ревизий для проверки, и команда распечатает
описание первого плохого коммита. Ссылка refs / bisect / bad будет указывать слева
при этом коммите.
Пополам сброс
После сеанса деления пополам, чтобы очистить состояние деления пополам и вернуться к исходной ГОЛОВЕ,
введите следующую команду:
$ git сброс пополам
По умолчанию это вернет ваше дерево к фиксации, которая была проверена до git
начало пополам. (Новый git bisect start также сделает это, поскольку он очищает старую bisect
штат.)
С необязательным аргументом вы можете вместо этого вернуться к другой фиксации:
$ git bisect reset
Например, git bisect reset bisect / bad проверяет первую плохую ревизию, а git
bisect reset HEAD оставит вас на текущем делении пополам и избежит переключения
совершает вообще.
Заместитель terms
Иногда вы ищете не коммит, который привел к поломке, а скорее
фиксация, которая вызвала изменение между каким-то другим «старым» состоянием и «новым» состоянием. Например,
возможно, вы ищете фиксацию, в которой было внесено конкретное исправление. Или ты мог бы быть
ищем первую фиксацию, в которой все имена файлов исходного кода были окончательно преобразованы
в соответствии со стандартом именования вашей компании. Или как там.
В таких случаях использование терминов «хороший» и «плохой» для обозначения «
состояние до изменения "и" состояние после изменения ". Вместо этого вы можете использовать
термины «старый» и «новый», соответственно, вместо «хорошего» и «плохого». (Но учтите, что вы
нельзя смешивать «хорошее» и «плохое» со «старым» и «новым» в одном сеансе.)
В этом более общем использовании вы предоставляете git bisect с "новым" коммитом, имеющим некоторое свойство
и «старый» коммит, у которого нет этого свойства. Каждый раз, когда git bisect проверяет
commit, вы проверяете, есть ли у этого коммита свойство. Если это так, отметьте фиксацию как «новую»;
в противном случае отметьте его как «старый». Когда деление пополам сделано, git bisect сообщит, какой
совершить введенное свойство.
Чтобы использовать «старые» и «новые» вместо «хороших» и «плохих», вы должны запустить git bisect start без
совершает в качестве аргумента, а затем выполните следующие команды, чтобы добавить коммиты:
git bisect old [ ]
чтобы указать, что фиксация была перед запрошенным изменением, или
git bisect new [ ...]
чтобы указать, что это было после.
Чтобы получить напоминание об используемых в настоящее время условиях, используйте
git делит пополам
Вы можете получить только старый (соответственно новый) термин с помощью git bisect term --term-old или git
разделенный пополам термин - срок-добро.
Если вы хотите использовать свои собственные термины вместо «плохой» / «хороший» или «новый» / «старый», вы можете
выберите любые имена, которые вам нравятся (кроме существующих подкоманд, разделенных пополам, таких как reset, start, ...),
начиная с деления пополам, используя
git bisect start --term-old --терм-новый
Например, если вы ищете фиксацию, которая привела к снижению производительности, вы
может использовать
git bisect start --term-старый быстрый --term-новый медленный
Или, если вы ищете фиксацию, исправляющую ошибку, вы можете использовать
git bisect start --term-new исправлено --term-old не работает
Затем используйте git bisect и git bisect вместо git bisect good и
git bisect bad, чтобы отмечать коммиты.
Пополам визуализации
Чтобы увидеть оставшихся в настоящее время подозреваемых в мерзавецвыполните следующую команду во время
процесс деления пополам:
$ git bisect визуализировать
view также может использоваться как синоним слова «визуализировать».
Если же линия индикатора ДИСПЛЕЙ переменная окружения не установлена, мерзавец журнал вместо этого используется. Вы также можете дать
параметры командной строки, такие как -p и --stat.
$ git представление пополам --stat
Пополам журнал и Bisect повторить
После того, как вы отметили исправления как хорошие или плохие, выполните следующую команду, чтобы показать, что изменилось.
сделано до сих пор:
$ git разделить журнал пополам
Если вы обнаружите, что допустили ошибку при указании статуса ревизии, вы можете
сохранить вывод этой команды в файл, отредактировать его, чтобы удалить неправильные записи, и
затем выполните следующие команды, чтобы вернуться в исправленное состояние:
$ git сброс пополам
$ git bisect воспроизвести этот файл
Избегающий тестов a совершать
Если в середине сеанса пополам вы знаете, что предложенная редакция не подходит
один для тестирования (например, он не может быть построен, и вы знаете, что сбой не имеет ничего
что делать с ошибкой, которую вы преследуете), вы можете вручную выбрать ближайший коммит и проверить, что
один вместо этого.
Например:
$ git bisect good / bad # предыдущий раунд был хорошим или плохим.
Деление пополам: после этого осталось проверить 337 ревизий (примерно 9 шагов)
$ git bisect visualize # ой, это неинтересно.
$ git reset --hard HEAD ~ 3 # попробуйте 3 ревизии, прежде чем
# был предложен
Затем скомпилируйте и протестируйте выбранную ревизию, а затем отметьте ревизию как хорошую или плохую.
обычным способом.
Пополам пропускать
Вместо того, чтобы выбирать ближайший коммит самостоятельно, вы можете попросить Git сделать это за вас:
выдача команды:
$ git bisect skip # Текущая версия не может быть протестирована
Однако, если вы пропустите фиксацию рядом с той, которую ищете, Git не сможет
чтобы точно сказать, какой из этих коммитов был первым плохим.
Вы также можете пропустить ряд коммитов вместо одного, используя нотацию диапазона.
Например:
$ git bisect пропустить v2.5..v2.6
Это сообщает процессу пополам, что никакая фиксация после v2.5, до v2.6 включительно, не должна
быть протестированным.
Обратите внимание, что если вы также хотите пропустить первую фиксацию диапазона, вы должны выполнить
команда:
$ git bisect пропустить v2.5 v2.5..v2.6
Это говорит процессу пополам, что коммиты между v2.5 и v2.6 (включительно) должны быть
пропущено.
Резка вниз деление пополам by предоставление больше параметры в Bisect Начало
Вы можете еще больше сократить количество испытаний, если знаете, какая часть дерева
вовлечены в проблему, которую вы отслеживаете, указав параметры пути при выдаче
команда запуска пополам:
$ git bisect start - arch / i386 include / asm-i386
Если вы заранее знаете более одного удачного коммита, вы можете сузить расстояние пополам на
указание всех хороших коммитов сразу после плохого коммита при выдаче
команда запуска пополам:
$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 -
# v2.6.20-rc6 - это плохо
# v2.6.20-rc4 и v2.6.20-rc1 хороши
Пополам пробег
Если у вас есть сценарий, который может определить, является ли текущий исходный код хорошим или плохим, вы можете
разделите пополам, введя команду:
$ git bisect запустить аргументы my_script
Обратите внимание, что сценарий (my_script в приведенном выше примере) должен завершиться с кодом 0, если
текущий исходный код хороший / старый, выход с кодом от 1 до 127 (включительно),
кроме 125, если текущий исходный код плохой / новый.
Любой другой код выхода прервет процесс разделения пополам. Следует отметить, что программа, которая
завершается через exit (-1) оставляет $? = 255, (см. выход(3) страница руководства), так как значение равно
нарезанный & 0377.
Если текущий исходный код не может быть протестирован, следует использовать специальный код выхода 125. Если
сценарий завершается с этим кодом, текущая ревизия будет пропущена (см. git bisect skip
выше). 125 было выбрано как наивысшее разумное значение для использования с этой целью, потому что 126
и 127 используются оболочками POSIX, чтобы сигнализировать о конкретном состоянии ошибки (127 для команды not
найдено, 126 - для команды найдена, но не исполняется - эти детали не имеют значения, так как они
- это нормальные ошибки в скрипте, если речь идет о пробеге пополам).
Часто вы можете обнаружить, что во время сеанса пополам вы хотите внести временные изменения
(например, s / # define DEBUG 0 / # define DEBUG 1 / в файле заголовка, или "ревизия, которая не имеет
этот коммит нуждается в применении этого патча, чтобы обойти другую проблему, это деление пополам не
интересует ") применительно к проверяемой ревизии.
Чтобы справиться с такой ситуацией, после внутреннего мерзавец Bisect находит следующую ревизию для тестирования,
сценарий может применить патч перед компиляцией, запустить настоящий тест и после этого решить
если ревизия (возможно, с нужным патчем) прошла проверку и затем перемотать дерево
до первозданного состояния. Наконец, скрипт должен выйти со статусом реального теста на
пусть цикл команд git bisect run определит конечный результат сеанса bisect.
ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ
- без кассы
Не проверяйте новое рабочее дерево на каждой итерации процесса деления пополам.
Вместо этого просто обновите специальную ссылку с именем БИСЕКТ_HEAD чтобы указать на
совершить, что следует протестировать.
Эта опция может быть полезна, когда тест, который вы выполняете на каждом этапе, не
требуется извлеченное дерево.
Если репозиторий пустой, предполагается --no-checkout.
ПРИМЕРЫ
· Автоматически делить неработающую сборку пополам между v1.2 и HEAD:
$ git bisect start HEAD v1.2 - # HEAD плохо, v1.2 хорошо
$ git bisect run make # "make" создает приложение.
$ git bisect reset # выйти из сеанса bisect
· Автоматически делить ошибку теста пополам между origin и HEAD:
$ git bisect start HEAD origin - # HEAD плохое, origin хорошее
$ git bisect run make test # "make test" сборки и тесты
$ git bisect reset # выйти из сеанса bisect
· Автоматически делить неработающий тестовый случай пополам:
$ кошка ~ / test.sh
#!/ Бен / ш
сделать || exit 125 # неработающие сборки пропускаются
~ / check_test_case.sh # тестовый пример пройден?
$ git bisect start HEAD HEAD ~ 10 - # виновник среди последних 10
$ git выполнить пополам ~ / test.sh
$ git bisect reset # выйти из сеанса bisect
Здесь мы используем собственный скрипт test.sh. В этом скрипте, если make не работает, мы пропускаем
текущая фиксация. check_test_case.sh должен выйти из 0, если тестовый пример пройден, и выйти из 1
в противном случае.
Безопаснее, если и test.sh, и check_test_case.sh находятся за пределами репозитория, чтобы
предотвратить взаимодействие между процессами пополам, создания и тестирования и скриптами.
· Автоматически делить пополам с временными модификациями (исправление):
$ кошка ~ / test.sh
#!/ Бен / ш
# настроить рабочее дерево, объединив ветку исправления
# а затем попытайтесь построить
если git merge --no-commit hot-fix &&
сделать
тогда
# запустить тест проекта и сообщить о его статусе
~ / check_test_case.sh
status = $?
еще
# сообщить вызывающему абоненту, что это невозможно проверить
статус = 125
fi
# отмените настройку, чтобы разрешить чистый переход к следующей фиксации
git reset - жесткий
# вернуть управление
exit $ status
При этом перед каждым запуском теста применяются модификации из ветки оперативного исправления, например, в случае
ваша среда сборки или тестирования изменилась, поэтому более старые версии могут нуждаться в исправлении, которое
более новые уже есть. (Убедитесь, что ветка исправления основана на фиксации, которая
содержится во всех ревизиях, которые вы делите пополам, так что слияние не втягивает
слишком много, или используйте git cherry-pick вместо git merge.)
· Автоматически делить неработающий тестовый случай пополам:
$ git bisect start HEAD HEAD ~ 10 - # виновник среди последних 10
$ git bisect run sh -c "make || exit 125; ~ / check_test_case.sh"
$ git bisect reset # выйти из сеанса bisect
Это показывает, что вы можете обойтись без сценария запуска, если вы напишете тест на одном
линии.
· Найдите хороший участок графа объекта в поврежденном репозитории
$ git bisect start HEAD [ ...] --no-checkout
$ git bisect запустить sh -c '
ХОРОШО = $ (git for-each-ref "--format =% (objectname)" refs / bisect / good- *) &&
git rev-list --objects BISECT_HEAD --not $ GOOD> tmp. $$ &&
git pack-objects --stdout> / dev / null
rc = $?
rm -f tmp. $$
test $ rc = 0 '
$ git bisect reset # выйти из сеанса bisect
В этом случае, когда мерзавец Bisect пробег Finishes, bisect / bad будет относиться к фиксации, имеющей
хотя бы один родитель, чей граф достижимости полностью проходим в требуемом смысле
by мерзавец упаковка объекты.
· Ищите исправление вместо регресса в коде
$ git начало пополам
$ git bisect new HEAD # текущая фиксация помечена как новая
$ git bisect old HEAD ~ 10 # десятый коммит с этого момента помечен как старый
или:
$ git bisect start --term-old не работает --term-new исправлено
Исправлено $ git bisect
$ git bisect сломанная ГОЛОВА ~ 10
Получающий помощь
Используйте git bisect, чтобы получить краткое описание использования, и git bisect help или git bisect -h, чтобы
получить подробное описание использования.
Используйте git-bisect в Интернете с помощью сервисов onworks.net