Есть ли какая-то "git rebase -dry-run", которая заранее сообщит мне о конфликтах?

Ответ 1

На момент написания (Git v2.6.1 v2.10.0) команда git rebase не предлагает опцию --dry-run. Невозможно узнать, прежде чем пытаться переустановить или не столкнетесь с конфликтами.

Однако, если вы запустите git rebase и ударите конфликт, процесс остановится и завершится с ненулевым статусом. Что вы можете сделать, это проверить статус выхода операции переадресации и, если он отличен от нуля, запустить git rebase --abort, чтобы отменить rebase:

git rebase ... || git rebase --abort

Ответ 2

Я подозреваю, что git rebase ... --dry-run невозможен по следующей причине.

Когда вы выполняете git rebase, git откатывается к начальной точке, затем постепенно применяйте исправления для каждой фиксации, чтобы обновить ветвь. Если он столкнется с конфликтом, он остановится и дождитесь, пока вы разрешите конфликт, прежде чем продолжить. Путь, который ребалансирует после этого конфликта, зависит от того, как вы разрешаете конфликт - если вы разрешите его определенным образом, который может ввести (или устранить) более поздние конфликты.

Таким образом, git rebase ... --dry-run сможет дать вам первый конфликт - отчеты о последующих конфликтах будут зависеть от того, как будет разрешен этот первый конфликт.

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

Ответ 3

Вы по-прежнему можете выполнять git rebase, играть с ним, как хотите, а не восстанавливать все изменения ранее. Предполагая, что вы сделали свою перестановку какой-либо ветки в master, и вам это не нравится:

• git reflog -20 - дает вам последние 20 позиций вашего HEAD с небольшим описанием
• git checkout <the_branch_name> - помещает HEAD в ветку
• git reset --hard <old_sha1_found_in_reflog> - помещает HEAD и ветку в старый ref, таким образом вы можете восстановить старую ветку.

Здесь есть некоторые механики:

• В любом случае вы НИКОГДА ничего не удаляете в git, а не с командами. Это сборщик мусора, который проходит и удаляет незаписанные ветки (по умолчанию 3 месяца). Таким образом, ваша ветка, начиная с переустановки, все еще существует.
• То же самое относится к той же ветке rebase, ее просто новое дерево, переписанное рядом со старым.
• Вся история rebase, а другая - в манипуляциях HEAD написана в reflog
• Вы можете использовать аннотации @{N} от reflog

Итак, после rebase ничего не теряется, вам просто нужно знать, как его найти и восстановить.

Например, вы можете поместить тег перед rebase, чем вернуться к нему или удалить его. он уклоняется от вас на всех этапах исследования SHA1.

Ответ 4

Если вы просто хотите увидеть, будет ли rebase успешным, но затем вы хотите "откат", вы всегда можете переместить кончик ветки назад к оригинальной фиксации. Просто пометьте или запишите оригинал SHA.

Или, может быть, проще, создайте новую временную ветвь, в которой нужно "сгенерировать" rebase:

git checkout your-branch
git checkout -b tmp
git rebase other-branch

Если он был успешным, но вы хотите "откат", your-branch нетронутым. Просто git branch -D tmp, и вы вернетесь туда, откуда вы начали.

Если возникли конфликты, и вы проделали определенную работу по их устранению, и теперь вы хотите сохранить переадресацию, просто переместите подсказку вашей ветки на tmp (а затем git branch -D tmp).