Desfazendo uma rebase do git

Como posso desfazer facilmente uma rebase do git?

Minhas idéias atuais são apenas abordagens manuais:

1. git checkout no pai de confirmação para os dois ramos
2. Crie uma ramificação temporária a partir daí
3. git cherry-pick tudo confirma manualmente
4. substituir a ramificação na qual refiz a nova ramificação criada manualmente

Na minha situação atual, isso funcionaria porque eu posso identificar facilmente commits de ambos os ramos (um era o meu material, o outro era o material do meu colega).

No entanto, minha abordagem me parece subótima e propensa a erros (digamos que eu acabei de fazer uma nova redefinição com duas de minhas próprias ramificações).

Esclarecimento : Estou falando de uma re-avaliação durante a qual um monte de confirmações foram repetidas. Não é só um.

A maneira mais fácil seria encontrar o commit principal do ramo, como era imediatamente antes do rebase começar no reflog ...

git reflog

e redefinir a ramificação atual (com as advertências usuais sobre ter certeza absoluta antes de redefinir com a --hardopção).

Suponha que o commit antigo estivesse HEAD@{5}no log ref:

git reset --hard HEAD@{5}

No Windows, pode ser necessário citar a referência:

git reset --hard "HEAD@{5}"

Você pode verificar o histórico do candidato antigo, basta fazer um git log HEAD@{5}( Windows git log "HEAD@{5}" :).

Se você não desabilitou os reflogs de ramificação, poderá fazer isso simplesmente git reflog branchname@{1}como uma rebase desanexa a cabeça da ramificação antes de recolocá-la na cabeça final. Gostaria de verificar isso novamente, embora não tenha verificado isso recentemente.

Por padrão, todos os reflogs são ativados para repositórios não bare:

[core]
    logAllRefUpdates = true

Na verdade, o rebase salva seu ponto de partida para ORIG_HEADque, geralmente, seja tão simples quanto:

git reset --hard ORIG_HEAD

No entanto, o reset, rebasee mergetodos salvam o HEADponteiro original para ORIG_HEADque, se você executou algum desses comandos desde o rebase que está tentando desfazer, precisará usar o reflog.

A resposta de Charles funciona, mas você pode fazer o seguinte:

git rebase --abort

para limpar após o reset.

Caso contrário, você poderá receber a mensagem “ Interactive rebase already started”.

Redefinir a ramificação para o objeto de confirmação pendente de sua dica antiga é obviamente a melhor solução, pois restaura o estado anterior sem fazer nenhum esforço. Mas se você perdeu esses commits (por exemplo, porque você coletou lixo no repositório enquanto isso, ou este é um novo clone), sempre é possível refazer a ramificação novamente. A chave para isso é o --ontointerruptor.

Digamos que você tenha um ramo de tópico chamado imaginativamente topic, que você tenha ramificado masterquando a dica masterera o 0deadbeefcommit. Em algum momento enquanto estava no topicgalho, você o fez git rebase master. Agora você quer desfazer isso. Aqui está como:

git rebase --onto 0deadbeef master topic

Isso levará todos os commits topicque não estiverem masterativados e os reproduzirá em cima de0deadbeef .

Com --onto, você pode reorganizar sua história em praticamente qualquer forma .

Diverta-se. :-)

Na verdade, eu coloquei uma tag de backup na ramificação antes de executar qualquer operação não trivial (a maioria das rebotes é trivial, mas eu faria isso se parecer complexa).

Então, restaurar é tão fácil quanto git reset --hard BACKUP.

Caso você tenha enviado sua ramificação para o repositório remoto (geralmente a origem) e depois tenha feito uma nova recuperação bem-sucedida (sem mesclagem) (git rebase --abort fornece "Nenhuma recuperação em andamento"), é possível redefinir facilmente a ramificação usando o comando:

git reset --hard origem / {branchName}

Exemplo:

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is ahead of 'origin/{branchName}' by 135 commits.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

$ ~/work/projects/{ProjectName} $ git reset --hard origin/{branchName}
HEAD is now at 6df5719 "Commit message".

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is up-to-date with 'origin/{branchName}.

nothing to commit, working directory clean

Usar reflognão funcionou para mim.

O que funcionou para mim foi semelhante ao descrito aqui . Abra o arquivo em .git / logs / refs com o nome da ramificação que foi rebatizada e localize a linha que contém "rebase finihed", algo como:

5fce6b51 88552c8f Kris Leech <me@example.com> 1329744625 +0000  rebase finished: refs/heads/integrate onto 9e460878

Faça o checkout do segundo commit listado na linha.

git checkout 88552c8f

Uma vez confirmado que isso continha minhas mudanças perdidas, eu me ramifiquei e soltei um suspiro de alívio.

git log
git checkout -b lost_changes

Para várias confirmações, lembre-se de que qualquer confirmação faz referência a todo o histórico que antecede essa confirmação. Portanto, na resposta de Charles, leia "o antigo commit" como "o mais novo do antigo commit". Se você redefinir para esse commit, todo o histórico que antecedeu esse commit reaparecerá. Isso deve fazer o que você quiser.

Seguindo a solução de @Allan e @Zearin, eu gostaria de poder simplesmente fazer um comentário, mas não tenho reputação suficiente, então usei o seguinte comando:

Em vez de fazer git rebase -i --abort (observe o -i ), eu tinha que simplesmente fazer git rebase --abort( sem o -i ).

Usando ambos -ie--abort ao mesmo tempo faz com que o Git me mostre uma lista de opções / uso.

Portanto, meu status de filial anterior e atual com esta solução é:

matbhz@myPc /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort

matbhz@myPc /my/project/environment (branch-123)
$

Se você reprovou com êxito contra a filial remota e git rebase --abortainda não pode, pode fazer alguns truques para salvar seu trabalho e não possui impulsos forçados. Suponha que sua ramificação atual que foi rebatizada por engano seja chamada your-branche esteja rastreandoorigin/your-branch

• git branch -m your-branch-rebased # renomear ramificação atual
• git checkout origin/your-branch # checkout para o estado mais recente conhecido por sua origem
• git checkout -b your-branch
• verificar git log your-branch-rebased, comparar git log your-branche definir confirmações ausentes doyour-branch
• git cherry-pick COMMIT_HASH para cada confirmação em your-branch-rebased
• faça suas alterações. Por favor, esteja ciente de que duas filiais locais estão associadas remote/your-branche você deve enviar apenasyour-branch

Digamos que eu refiz o master para o meu ramo de recursos e recebo 30 novos commits que quebram algo. Descobri que muitas vezes é mais fácil remover os commits ruins.

git rebase -i HEAD~31

Rebase interativo para os últimos 31 commits (não dói se você escolher muitos).

Simplesmente aceite os commits dos quais você deseja se livrar e marque-os com "d" em vez de "pick". Agora, as confirmações são excluídas efetivamente, desfazendo a rebase (se você remover apenas as confirmações que acabou de obter ao rebasear).

Para iniciantes / qualquer pessoa com muito medo de fazer uma redefinição forçada, você pode retirar o commit do reflog e salvá-lo como um novo ramo.

git reflog

Encontre o commit antes de começar a rebasear. Pode ser necessário rolar mais para baixo para encontrá-lo (pressione Enter ou PageDown). Anote o número HEAD e substitua 57:

git checkout HEAD@{57}

Revise a ramificação / confirmações, se parecer bom, crie uma nova ramificação usando este HEAD:

git checkout -b new_branch_name

Se você estiver em uma filial, poderá usar:

git reset --hard @{1}

Não há apenas um log de referência para HEAD (obtido por git reflog), também há reflogs para cada ramo (obtido por git reflog <branch>). Portanto, se você estiver ligado master, git reflog masterlistará todas as alterações nesse ramo. Você pode referir-se que as mudanças por master@{1}, master@{2}etc.

git rebase normalmente mudará HEAD várias vezes, mas a ramificação atual será atualizada apenas uma vez.

@{1}é simplesmente um atalho para a ramificação atual ; portanto, é igual a master@{1}se você estiver ativado master.

git reset --hard ORIG_HEADnão funcionará se você tiver usado git resetdurante uma interação rebase.

O que eu costumo fazer é git reset #commit_hash

até o último commit, onde acho que rebase não teve efeito.

então git pull

Agora sua ramificação deve corresponder exatamente como mestre e confirmações rebased não devem estar nela.

Agora pode-se escolher os commits neste ramo.

Tentei todas as sugestões com redefinição e reflog sem sucesso. A restauração do histórico local do IntelliJ resolveu o problema de arquivos perdidos

git reset --hard origem / {branchName}

é a solução correta para redefinir todas as alterações locais feitas por rebase.

Se você estragar alguma coisa dentro de uma rebase do git, por exemplo git rebase --abort, enquanto você tiver arquivos não confirmados, eles serão perdidos e git reflognão ajudarão. Isso aconteceu comigo e você precisará pensar fora da caixa aqui. Se você tiver sorte como eu e usar o IntelliJ Webstorm, poderá right-click->local historye poderá reverter para um estado anterior de seus arquivos / pastas, independentemente dos erros cometidos com o software de controle de versão. É sempre bom ter outro à prova de falhas em execução.