Резюме
Сообщение об ошибке
Невозможно «сквош» без предыдущего коммита
означает, что вы, вероятно, пытались «раздавить вниз». Git всегда раздавливает новый коммит в более старый коммит или «вверх», как показано в интерактивном списке задач перебазирования, то есть в коммите предыдущего линия. Изменение команды в самой первой строке списка задач на squash
всегда будет приводить к этой ошибке, так как нет ничего для первого коммита, в который можно попасть.
Исправление
Сначала вернитесь туда, откуда вы начали
$ git rebase --abort
Скажи, что твоя история
$ git log --pretty=oneline
a931ac7c808e2471b22b5bd20f0cad046b1c5d0d c
b76d157d507e819d7511132bdb5a80dd421d854f b
df239176e1a2ffac927d8b496ea00d5488481db5 a
То есть a был первым коммитом, затем b и, наконец, c. После совершения c мы решаем раздавить b и c вместе:
(Примечание. Запуск git log
направляет вывод в пейджер, less
по умолчанию на большинстве платформ. Чтобы выйти из пейджера и вернуться в командную строку, нажмите q
ключ.)
Запуск git rebase --interactive HEAD~2
дает вам редактор с
pick b76d157 b
pick a931ac7 c
# Rebase df23917..a931ac7 onto df23917
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
(Обратите внимание, что этот список задач находится в обратном порядке по сравнению с выводом git log
.)
Изменение b's pick
на squash
приведет к ошибке, которую вы видели, но если вместо этого вы нажмете c на b (новый коммит на более старый или «сдвинуть вверх»), изменив список задач на
pick b76d157 b
squash a931ac7 c
и сохраните-выйдите из вашего редактора, вы получите другой редактор, содержимое которого
# This is a combination of 2 commits.
# The first commit's message is:
b
# This is the 2nd commit message:
c
Когда вы сохраняете и выходите, содержимое отредактированного файла становится сообщением коммита нового комбинированного коммита:
$ git log --pretty=oneline
18fd73d3ce748f2a58d1b566c03dd9dafe0b6b4f b and c
df239176e1a2ffac927d8b496ea00d5488481db5 a
Примечание об истории перезаписи
Интерактивный ребаз переписывает историю. Попытка отправить на удаленный компьютер, содержащий старую историю, не удастся, потому что это не перемотка вперед.
Если ветка, которую вы перебазировали, является веткой темы или функции , в которой вы работаете самостоятельно , ничего страшного. Для перемещения в другое хранилище потребуется опция --force
, или, в качестве альтернативы, вы можете, в зависимости от разрешений удаленного хранилища, сначала удалить старую ветку, а затем переместить перебазированную версию. Примеры тех команд, которые потенциально могут разрушить работу, выходят за рамки этого ответа.
Переписывание уже опубликованной истории в ветке, в которой вы работаете с другими людьми, без очень веских причин, таких как утечка пароля или других конфиденциальных данных, вынуждает ваших соавторов работать и антисоциально и раздражает других Разработчики. В разделе «Восстановление из исходной ребазы» в документации git rebase
поясняется, с дополнительным акцентом.
Перебазирование (или любая другая форма переписывания) ветки, на которой работают другие, является плохой идеей: любой последующий поток вынужден вручную исправлять свою историю. В этом разделе объясняется, как это исправить с точки зрения нижестоящего. Реальное исправление, однако, было бы, во-первых, избегать перебазирования восходящего потока. & hellip;