Sumário
A mensagem de erro
Não é possível 'squash' sem uma confirmação anterior
significa que você provavelmente tentou "esmagar para baixo". O Git sempre coloca uma confirmação mais recente em uma confirmação mais antiga ou "para cima", conforme exibido na lista de tarefas de rebase interativa, ou seja, em uma confirmação na linha anterior. Alterar o comando na primeira linha da sua lista de tarefas squash
sempre produzirá esse erro, pois não há nada para o primeiro commit ser compactado.
O conserto
Primeiro volte para onde você começou
$ git rebase --abort
Diga que sua história é
$ git log --pretty=oneline
a931ac7c808e2471b22b5bd20f0cad046b1c5d0d c
b76d157d507e819d7511132bdb5a80dd421d854f b
df239176e1a2ffac927d8b496ea00d5488481db5 a
Ou seja, a foi o primeiro commit, depois b e finalmente c. Depois de confirmar c, decidimos esmagar bec juntos:
(Nota: A execução git log
direciona sua saída para um pager, less
por padrão na maioria das plataformas. Para sair do pager e retornar ao prompt de comando, pressione a q
tecla.)
A execução git rebase --interactive HEAD~2
fornece um editor com
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.
#
(Observe que esta lista de tarefas está na ordem inversa em comparação com a saída de git log
.)
Alterar b's pick
para squash
resultará no erro que você viu, mas, em vez disso, você esmaga c em b (confirmação mais recente na mais antiga ou “esmaga para cima”) alterando a lista de tarefas para
pick b76d157 b
squash a931ac7 c
e salvar seu editor, você receberá outro editor cujo conteúdo é
# This is a combination of 2 commits.
# The first commit's message is:
b
# This is the 2nd commit message:
c
Quando você salva e sai, o conteúdo do arquivo editado se torna uma mensagem de confirmação da nova confirmação combinada:
$ git log --pretty=oneline
18fd73d3ce748f2a58d1b566c03dd9dafe0b6b4f b and c
df239176e1a2ffac927d8b496ea00d5488481db5 a
Nota sobre como reescrever o histórico
O rebase interativo reescreve o histórico. Tentar enviar para um controle remoto que contém o histórico antigo falhará porque não é um avanço rápido.
Se a ramificação que você reformulou for uma ramificação de tópico ou recurso na qual você está trabalhando sozinho , não é grande coisa. Enviar para outro repositório exigirá a --force
opção ou, alternativamente, você poderá, dependendo das permissões do repositório remoto, primeiro excluir a ramificação antiga e depois enviar a versão rebaseada. Exemplos desses comandos que potencialmente destruirão o trabalho estão fora do escopo desta resposta.
Reescrever o histórico já publicado em uma ramificação na qual você está trabalhando com outras pessoas sem uma boa razão, como deixar uma senha ou outros detalhes sensíveis forçar o trabalho de seus colaboradores e é antissocial e incomodará outros desenvolvedores. A seção “Recuperando de uma rebase upstream” na git rebase
documentação explica, com ênfase adicional.
Reprocessar (ou qualquer outra forma de reescrita) uma ramificação na qual outros se basearam é uma má idéia: qualquer pessoa a jusante é forçada a corrigir manualmente seu histórico. Esta seção explica como fazer a correção do ponto de vista do downstream. A solução real, no entanto, seria evitar rebasear o upstream em primeiro lugar. …