Eu estava tentando editar uma mensagem de confirmação antiga, conforme explicado aqui .
A questão é que agora, quando tento executar rebase -i HEAD~5, diz interactive rebase already started.
Então, eu tento: git rebase --continuemas recebi este erro:
error: Ref refs/heads/master is at 7c1645b447a8ea86ee143dd08400710c419b945b but expected c7577b53d05c91026b9906b6d29c1cf44117d6ba
fatal: Cannot lock the ref 'refs/heads/master'.
Alguma ideia?
Respostas:
Diz:
Quando você salva e sai do editor, ele volta para o último commit nessa lista e o coloca na linha de comando com a seguinte mensagem:
$ git rebase -i HEAD~3
Stopped at 7482e0d... updated the gemspec to hopefully work better
You can amend the commit now, with
Isso não significa:
Digite de novo
git rebase -i HEAD~3
Tente não digitar git rebase -i HEAD~3ao sair do editor, e deve funcionar bem.
(caso contrário, em sua situação específica, git rebase -i --abortpoderá ser necessário redefinir tudo e permitir que você tente novamente)
Como Dave Vogt menciona nos comentários, git rebase --continueé para ir para a próxima tarefa no processo de reformulação, depois de alterar o primeiro commit .
Além disso, Gregg Lind menciona em sua resposta o rewordcomando degit rebase :
Substituindo o comando "pick" pelo comando "edit", você pode dizer
git rebasepara parar depois de aplicar essa confirmação, para poder editar os arquivos e / ou a mensagem de confirmação, alterar a confirmação e continuar com a rebasagem.Se você deseja apenas editar a mensagem de confirmação de uma confirmação, substitua o comando "
pick" pelo comando "reword" , desde Git1.6.6 (janeiro de 2010) .Ele faz a mesma coisa '
edit' durante uma rebase interativa, exceto que permite editar a mensagem de confirmação sem retornar o controle ao shell . Isso é extremamente útil.
Atualmente, se você deseja limpar suas mensagens de confirmação, você deve:
$ git rebase -i next
Em seguida, defina todas as confirmações para 'editar'. Então em cada um:
# Change the message in your editor.
$ git commit --amend
$ git rebase --continue
Usar '
reword' em vez de 'edit' permite ignorar as chamadasgit-commitegit-rebase.
Como Gregg Lind sugeriu, você pode usar a reformulação para ser solicitado a alterar apenas a mensagem de confirmação (e deixar a confirmação intacta de outra forma):
git rebase -i HEAD~n
Aqui nestá a lista dos últimos n commits.
Por exemplo, se você usar git rebase -i HEAD~4, poderá ver algo assim:
pick e459d80 Do xyz
pick 0459045 Do something
pick 90fdeab Do something else
pick facecaf Do abc
Agora substitua pick por reformular os commits dos quais você deseja editar as mensagens:
pick e459d80 Do xyz
reword 0459045 Do something
reword 90fdeab Do something else
pick facecaf Do abc
Saia do editor depois de salvar o arquivo e, em seguida, você será solicitado a editar as mensagens para os commits que você marcou como reformular , em um arquivo por mensagem. Note que ela já teria sido muito mais simples de apenas editar as mensagens cometer quando substituiu pickcom reword, mas fazer isso não tem efeito.
Saiba mais na página do GitHub sobre Alterando uma mensagem de confirmação .
Agora, o Git Rebase Interactive agora tem uma opção de "reformulação", o que torna isso muito menos doloroso!
reword, por que o git não permite editar as mensagens de confirmação desse arquivo com a lista de confirmações? Em vez disso, ele iniciará o editor com um arquivo de mensagem de confirmação por rewordlinha. Isso é desnecessário. Mesmo que outras ações que não sejam pickou rewordexijam o lançamento de comandos externos, rewordnão exigiriam isso.
Só queria fornecer uma opção diferente para isso. No meu caso, costumo trabalhar em meus ramos individuais e depois me fundir para dominar, e os compromissos individuais que faço com meu local não são tão importantes.
Devido a um gancho git que verifica o número do ticket apropriado no Jira, mas diferencia maiúsculas de minúsculas, fui impedido de enviar meu código. Além disso, o commit foi feito há muito tempo e eu não queria contar quantos commits para voltar ao rebase.
Então, o que fiz foi criar uma nova ramificação a partir do mestre mais recente e compactar todas as confirmações da ramificação do problema em uma única confirmação na nova ramificação. Foi mais fácil para mim e acho que é uma boa ideia tê-lo aqui como referência futura.
Do mestre mais recente:
git checkout -b new-branch
Então
git merge --squash problem-branch
git commit -m "new message"
rebase -ipor cerca de duas horas e sem sucesso. Meu commit ficou atrás de 18 commits, então você pode imaginar. Essa foi a maneira mais simples e prática que pude encontrar sem precisar usar o rebase. Valeu amigo!
Aqui está um Gist muito bom que abrange todos os casos possíveis: https://gist.github.com/nepsilon/156387acf9e1e72d48fa35c4fabef0b4
Visão geral:
git rebase -i HEAD~X
# X is the number of commits to go back
# Move to the line of your commit, change pick into edit,
# then change your commit message:
git commit --amend
# Finish the rebase with:
git rebase --continue
git rebase --continuevai para a próxima tarefa no processo de reformulação, depois de alterar o primeiro commit.