Підсумок
Повідомлення про помилку
Неможливо "сквош" без попереднього виконання
означає, що ви, ймовірно, намагалися "скосити вниз". Git завжди стискає новіші зобов'язання на більш старий або "вгору", як це переглядається в списку todo інтерактивних баз даних, тобто в команду в попередньому рядку. Зміна команди в першому рядку списку todo 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 pick
на, squash
це призведе до помилки, яку ви побачили, але якщо замість цього, ви зімкнете c на b (новіший перехід у старіший або "збиття вгору"), змінивши список todo на
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
документації пояснює, з додатковим акцентом.
Звільнення (або будь-яка інша форма переписування) гілки, над якою працюють інші, - погана ідея: будь-хто після цього змушений вручну виправити свою історію. У цьому розділі пояснюється, як зробити виправлення з точки зору нижньої течії. Справжнім виправленням було б у першу чергу уникнути повторного викиду вгору за течією. …