Блог

Какая-то проверка за последние 3 дня нарушила один из наших модульных тестов (и почему, совсем не ясно).

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

Что приводит к вопросам:

1. Как мне получить список всех идентификаторов (?) кода, переданного в ветку за последние 3 дня.
2. Как мне затем извлечь эту копию кода (для этого конкретного идентификатора)?

Мы используем Git через VSO (теперь Azure DevOps), если это имеет значение.

спасибо — дэйв

ОБНОВИТЕ, чтобы предоставить немного больше информации о том, как использовать bisect

То, что вы описываете, — это именно то, что git bisect делает. Затем все, что вам нужно, это определить один рабочий коммит (до появления ошибки) и один неработающий коммит (предположительно, текущий).

Теперь весь смысл bisect в том, чтобы определить, когда все было в последний раз хорошо (или в первый раз плохо), потому что вы не знаете. Итак, когда вы определяете «один рабочий коммит», сделать его более свежим немного быстрее, но этого недостаточно, чтобы иметь значение. (Особенно потому, что любое время, которое вы тратите на то, чтобы быть более точным в настройке начального piont, — это время, которое bisect мог бы потратить более эффективно на поиск именно того коммита, где была введена ошибка.)

Итак, если вы знаете, что неделю назад у вас локально была проверена хорошая копия (до ошибки) на master, вы можете предоставить

 master@{1 week ago}
  

Это зависит от локального рефлога, поэтому работает только из репозитория, у которого на тот момент была проверена хорошая копия. Если это непрактично, вы можете использовать

 git rev-list --until='1 week ago' -n1 master
  

чтобы получить последний коммит, созданный (в соответствии с метаданными коммита) не менее 1 недели назад. Итак, что-то вроде

 git bisect start $(git rev-list --until='1 week ago' -n1 master) master
  

Для любого из вышеуказанных обозначений вы можете использовать 3 days вместо 1 week , и это было бы немного эффективнее — т. Е. вы могли бы ожидать на 1 или 2 меньше поисков, прежде чем ошибка будет обнаружена.

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

Немного в сторону, но будьте осторожны — в наши дни довольно популярно создавать «более чистые» истории путем перебазирования каждой ветки перед интеграцией ее в основную. И хотя эти «более чистые» истории действительно более линейны и просты, они также на самом деле с большей вероятностью будут грязными в том смысле, что они содержат коммиты, которые никогда не тестировались. Если один из этих коммитов завершается неудачей модульных тестов по причинам, отличным от вашей ошибки — таким как несоответствие слиянию, которое было устранено в более позднем коммите, то использовать bisect внезапно становится не так просто, поскольку просто зеленый / красный статус вашего набора модульных тестов не скажет вам, присутствует ли ваша ошибка.

Но это было бы проблемой для стратегии поиска ошибок, которую вы описываете в целом (не только для bisect ). Итак, если отслеживание ошибки по истории вообще возможно, то bisect это лучший способ сделать это.