У меня есть ветвь с множеством коммитов.
Ответ 1
Пока вы находитесь на ветке feature выполните:
git rebase --interactive --exec "ant rebuild test" C
Это приведет к тому, что git начнет работу с фиксацией C, воспроизведет вашу работу сверху, и она будет запускать ваши тесты после каждого фиксации, которые она применяет во время фазы воспроизведения.
Надеемся, что ваша задача ant будет иметь ненулевой код выхода, если ваши тесты не пройдут. В этом случае git остановится, как только тесты потерпят неудачу. Вы сразу же находитесь в правильном положении, чтобы внести поправки в силу, чтобы тесты снова были счастливы. После того, как вы внесли поправки, просто выполните git rebase --continue, как обычно, и git будет продолжать проверять все, что вы совершаете.
Ответ 3
Чтобы добавить к отличному ответу OP yankee, Git 2. 5+ предоставит более надежный опыт git rebase --interactive --exec, особенно в случае неудачного выполнения.
На самом деле, смотрите новый --reschedule-failed-exec из Git 2.21 в последней части этого ответа.
См совершать b12d3e9 [22 мая 2015], и совершить 1d968ca [22 мая 2015] по Матьё Moy (moy).
(Объединено Junio C Hamano - gitster - в коммите a6be52e, 01 июня 2015 г.)
Команда ' exec ' отправляет текущий коммит в stopped-sha, который должен содержать исходный коммит (до ребазинга).
В результате, если команда ' exec ' завершится неудачно, следующая ' git rebase --continue ' отправит текущий коммит как ловушку после перезаписи.
Полная документация:
rebase -i: исправлена rebase -i post-rewrite неудачной команды exec
Обычно, когда " git rebase " останавливается перед завершением ребазирования, это дает пользователю возможность редактировать коммит (например, с помощью команды " edit ").
В таких случаях " git rebase " оставляет перезаписываемый sha1 коммита в "$state_dir"/stopped-sha, а последующее " git rebase --continue " вызывает этот перехват post-rewrite с этим sha1 как <old-sha1> Аргумент на post-rewrite крючок.
Случай остановки " git rebase " из-за неудачной команды " exec " отличается: он дает пользователю возможность изучить или исправить ошибку, но не перестает говорить "здесь коммит для редактирования, используйте --continue когда все готово ".
Таким образом, нет причин вызывать ловушку post-rewrite для команд exec.
Если бы пользователь переписал коммит, это было бы с ' git commit --amend ', который уже вызывал хук post-rewrite.
Исправьте поведение, чтобы:
- не оставлять файл
stopped-sha в случае неудачной команды exec, - и научить '
git rebase --continue ' пропускать record_in_rewritten если не найден файл git rebase --continue stopped-sha.
Чтобы упростить управление ошибочными директивами exec, связанными с перебазированием, Git 2.21 (Q1 2019) вводит --reschedule-failed-exec с " git rebase -i ", который научился повторно выполнять команду, заданную с помощью " exec " для запуска после того, как это не удалось в последний раз.
Смотрите коммит 81ef8ee, коммит 969de3f, коммит d421afa (10 декабря 2018 г.) Иоганнеса dscho (dscho).
(Объединено Junio C Hamano - gitster - в коммите d9d9ab0, 29 января 2019 г.)
rebase: ввести --reschedule-failed-exec
--exec вариант использования опции --exec - проверка правильности компиляции каждого коммита в ветке темы с помощью git rebase -x make <base>.
Однако, когда exec в такой перебазировке терпит неудачу, это не перепланировано, что в этом случае не особенно полезно.
Позвольте предложить флаг, чтобы перепланировать неудачные команды exec.
Основано на идее Пола Мореля.
Страница man git rebase теперь включает в себя:
--reschedule-failed-exec::
--no-reschedule-failed-exec::
Автоматически перепланировать команды exec которые потерпели неудачу.
Это имеет смысл только в интерактивном режиме (или когда была предоставлена опция --exec).
А также:
rebase: ввести ярлык для --reschedule-failed-exec
Немного обременительно выписывать --reschedule-failed-exec перед -x <cmd> все время; Давайте представим удобную опцию, чтобы сделать оба одновременно: -y <cmd>.
Примечание: первый коммит был возвращен в See commit e11ff89 (06 Feb 2019), а коммит 81ef8ee (10 Dec 2018) - Johannes Schindelin (dscho).
(Объединено Junio C Hamano - gitster - в коммите b966813, 09 февраля 2019 г.)
Отменить "rebase: ввести ярлык для --reschedule-failed-exec"
Этот патч был внесен только в качестве пробного "мы могли бы ввести удобный короткий вариант, если мы не хотим изменять поведение по умолчанию в долгосрочной перспективе", открывая дискуссию о том, согласны ли другие люди с осуждением текущего поведения в пользу изменения графика поведение.
Но консенсус в списке рассылки Git заключался в том, что было бы целесообразно показать предупреждение в ближайшем будущем и перевернуть default rebase.rescheduleFailedExec чтобы перепланировать rebase.rescheduleFailedExec команды exec по умолчанию.
Так что давайте вернемся к тому -y который добавил короткую опцию -y которую мы согласились, не было необходимости или нежелательно.
Также в Git 2.21 (февраль 2019 г.): " git rebase -x $cmd " не отклонял многострочную команду, даже если команда не способна обработать такую команду.
Это теперь отклонено заранее.
См. Коммит c762aad (29 января 2019 г.) Филиппа Вуда (phillipwood).
(Объединено Junio C Hamano - gitster - в коммите 96e6547, 07 февраля 2019 г.)
rebase -x: команда проверки rebase -x
Если пользователь дает пустой аргумент --exec то git создает список --exec которые он не может проанализировать. Rebease начинает работать, прежде чем выдает ошибку:
error: missing arguments for exec
error: invalid line 2: exec
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.
Вместо этого проверьте наличие пустых команд перед началом ребазинга.
Также убедитесь, что команда не содержит никаких новых строк, поскольку формат списка задач не справляется с многострочными командами.
Обратите внимание, что это меняет поведение, прежде чем это можно сделать:
git rebase --exec='echo one
exec echo two'
и было бы вставить две EXEC строки в todo списке, теперь выдаст ошибку.
В Git 2.23 переменная конфигурации rebase.rescheduleFailedExec должна быть эффективна только при выполнении интерактивной перебазировки и не должна влиять на что-либо при запуске неинтерактивной -i, что не имело место.
Это было исправлено.
См. Коммит 906b639 (01 июля 2019 г.) Йоханнеса dscho (dscho).
(Объединено Junio C Hamano - gitster - в коммите 64096fb, 11 июля 2019 г.)
rebase --am: игнорировать rebase.rescheduleFailedExec
Команда exec специфична для интерактивного бэкэнда, поэтому нетрадиционным ребятам -i не имеет смысла учитывать эту настройку конфигурации.
Мы по-прежнему хотим выдавать ошибку, если, конечно, не [n02] нетерабельная перезагрузка запускается с --reschedule-failed-exec.
Об этом сообщает Vas Sudanagunta через commit 969de3f.
