ОБНОВЛЕНИЕ , чтобы предоставить немного больше информации о том, как использовать bisect
То, что вы описываете, это именно то, что делает git bisect.Тогда все, что вам нужно, - это идентифицировать один рабочий коммит (до появления ошибки) и один битый коммит (предположительно текущий).
Теперь весь смысл 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 меньше запросов до того, как будет выявлена ошибка.
Так что нет смысла пытаться предварительно проверить, есть ли ошибка в коммите, если вы не уверены;Вы можете просто использовать более старый коммит.Но если по какой-либо причине вы действительно хотите, вы можете использовать те же нотации, чтобы проверить фиксацию за определенное время, а затем протестировать ее так, как вам нравится.
Aнемного в стороне, но будьте осторожны - в наши дни довольно популярно делать «более чистые» истории, перебирая каждую ветку перед тем, как интегрировать ее в основную линию.И хотя эти «более чистые» истории действительно более линейны и просты, на самом деле они также на более вероятно будут грязными в том смысле, что они содержат коммиты, которые никогда не тестировались.Если один из этих коммитов не проходит модульные тесты по причинам, отличным от вашей ошибки - например, из-за несоответствия слияния, которое было удалено в последующем коммите, то использование bisect внезапно не так просто, так как просто зеленый / красный статусваш набор модульных тестов не скажет вам, присутствует ли ваша ошибка.
Но это будет проблемой для стратегии поиска ошибок, которую вы описываете в целом (не только для bisect).Так что если отслеживание ошибки в истории вообще возможно, тогда bisect - лучший способ сделать это.