Devido a algumas más escolhas, meu repositório Git local está atualmente cinco commits à frente da origem e não está em bom estado. Eu quero me livrar de todos esses commits e começar de novo.

Obviamente, excluir meu diretório de trabalho e re-clonar faria isso, mas fazer o download de tudo do GitHub novamente parece exagero e não é um bom uso do meu tempo.

Talvez git revertseja o que eu preciso, mas não quero acabar com 10 confirmações antes da origem (ou mesmo seis), mesmo que ele retorne o código ao estado correto. Eu só quero fingir que a última meia hora nunca aconteceu.

Existe um comando simples que fará isso? Parece um caso de uso óbvio, mas não estou encontrando nenhum exemplo disso.

Observe que esta pergunta é especificamente sobre confirmações , não sobre:

• arquivos não rastreados
• mudanças sem estágio
• mudanças encenadas, mas não confirmadas

Se o excesso de confirmações estiver visível apenas para você, basta fazer git reset --hard origin/<branch_name> o retorno para onde está a origem. Isso redefinirá o estado do repositório para a confirmação anterior e descartará todas as alterações locais.

Fazer um git revertfaz novas confirmações para remover as confirmações antigas de uma maneira que mantém a história de todos sã.

Simplesmente exclua seu ramo mestre local e recrie-o da seguinte maneira:

git branch -D master
git checkout origin/master -b master

Tentar:

git reset --hard <the sha1 hash>

para repor a cabeça onde quer que você esteja. Use o gitk para ver em qual commit você deseja estar. Você também pode redefinir no gitk.

Exclua a confirmação mais recente:

git reset --hard HEAD~1

Exclua a confirmação mais recente, sem destruir o trabalho que você fez:

git reset --soft HEAD~1

Se você estiver usando o aplicativo Atlassian SourceTree , poderá usar a opção de redefinição no menu de contexto.

Na sua tentativa de ramificação:

git reset --hard origin/<branch_name>

Valide a reversão (para o estado, sem confirmações locais), usando " git log" ou " git status".

git reset --hard @{u}* exclui todas as suas alterações locais na ramificação atual, incluindo confirmações. Estou surpreso que ninguém tenha postado isso ainda, considerando que você não precisará procurar o que se comprometer a reverter ou brincar com os ramos.

_{* Ou seja, redefina a ramificação atual em - @{upstream}geralmente origin/<branchname>, mas nem sempre}

Para ver / obter o ID SHA-1 do commit, você também quer voltar

gitk --all

Para reverter para esse commit

git reset --hard sha1_id

!Nota. Todas as confirmações feitas após essa confirmação serão excluídas (e todas as suas modificações no projeto). Então, primeiro é melhor clonar o projeto em outra ramificação ou copiar em outro diretório.

Eu tive uma situação em que queria remover uma confirmação que não foi enviada por push, mas a confirmação foi antes de outra. Para fazer isso, usei o seguinte comando

git rebase -i HEAD~2 -> irá refazer os dois últimos commits

E usei 'drop' para a assinatura de confirmação que eu queria remover.

Remover arquivos não rastreados (alterações locais não confirmadas)

git clean -df

Excluir permanentemente todas as confirmações locais e obter a confirmação remota mais recente

git reset --hard origin/<branch_name>

Para confirmações locais que não estão sendo enviadas por push, você também pode usar git rebase -ipara excluir ou compactar uma confirmação.

A solução simples será combinar o ramo principal local HEAD com a origem / ramo principal HEAD

git reset --hard origin/master

PS: origem / mestre - é um ponteiro remoto para o ramo principal. Você pode substituir o mestre por qualquer nome de filial

Antes de responder, vamos adicionar alguns antecedentes, explicando o que é isso HEAD. uma vez que algumas das opções abaixo resultarão em desanexação da cabeça

First of all what is HEAD?

HEADé simplesmente uma referência ao commit atual (mais recente) no branch atual.
Só pode haver um single HEADa qualquer momento. (excluindo git worktree)

O conteúdo de HEADé armazenado dentro .git/HEADe contém os 40 bytes SHA-1 da confirmação atual.

detached HEAD

Se você não está no último commit, o que significa que HEADestá apontando para um commit anterior no histórico detached HEAD.

Na linha de comando, será semelhante a este- SHA-1 em vez do nome do ramo, pois ele HEADnão está apontando para a ponta do ramo atual

Algumas opções sobre como recuperar de um HEAD desanexado:

git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

Isso fará o checkout do novo ramo apontando para o commit desejado.
Este comando fará checkout para um determinado commit.
Nesse ponto, você pode criar uma ramificação e começar a trabalhar a partir deste ponto.

# Checkout a given commit. 
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

Você sempre pode usar o reflogtambém.
git reflogexibirá qualquer alteração que tenha atualizado HEADe o check-out da entrada de reflog desejada HEADretornará a esta confirmação.

Sempre que o HEAD for modificado, haverá uma nova entrada no reflog

git reflog
git checkout HEAD@{...}

Isso o levará de volta ao seu commit desejado

git reset --hard <commit_id>

"Mova" seu HEAD de volta para o commit desejado.

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts if you've modified things which were
# changed since the commit you reset to.

• Nota: ( Desde o Git 2.7 ),
  você também pode usá-lo git rebase --no-autostash.

git revert <sha-1>

"Desfazer" o intervalo de confirmação ou confirmação fornecido.
O comando reset irá "desfazer" quaisquer alterações feitas no commit fornecido.
Um novo commit com o patch de desfazer será confirmado enquanto o commit original também permanecerá no histórico.

# add new commit with the undo of the original one.
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>

Este esquema ilustra qual comando faz o quê.
Como você pode ver lá, reset && checkoutmodifique o arquivo HEAD.

Para os interessados ​​na solução do Visual Studio, aqui está o detalhamento:

1. Na Team Explorerjanela, conecte-se ao repositório de destino.
2. Em seguida Branches, em , clique com o botão direito do mouse na filial de interesse e selecione View history.
3. Clique com o botão direito do mouse em uma confirmação na Historyjanela e escolha Reset -> Delete changes (--hard).

Isso descartará as confirmações locais e redefinirá o estado do seu repo para a confirmação selecionada. Ou seja, suas alterações após a retirada do repositório serão perdidas.

Se o seu ramo está à frente de ' origin/XXX' em 5 confirma.

Você pode emitir:

git reset --hard HEAD~5

E deve remover os últimos 5 commits.

git reset --hard <SHA-Code>

Isso será útil se você cometeu alguns erros em sua cópia local e deseja garantir que não seja enviado por push à sua filial remota.

O Código SHA pode ser obtido consultando a versão web do seu painel git para o último commit na ramificação.

Dessa forma, você pode ser sincronizado com a última confirmação na ramificação.

Você pode fazer isso git pulldepois de concluir com êxito a reinicialização completa para confirmar que não há nada novo em sin.

Sua filial está atualizada com Origin/<Branch Name>

Se você deixar seu repositório local em uma bagunça completa, uma maneira confiável de jogar fora os commits locais no Git é ...

1. Use "git config --get remote.origin.url" para obter o URL de origem remota
2. Renomeie a pasta git local para "my_broken_local_repo"
3. Use "git clone <url_from_1>" para obter uma cópia local nova do repositório remoto do git

Na minha experiência, o Eclipse lida com o mundo mudando muito bem. No entanto, pode ser necessário selecionar projetos afetados no Eclipse e limpá-los para forçar o Eclipse a reconstruí-los. Eu acho que outros IDEs também podem precisar de uma reconstrução forçada.

Um benefício secundário do procedimento acima é que você descobrirá se o seu projeto depende de arquivos locais que não foram colocados no git. Se você achar que estão faltando arquivos, poderá copiá-los de "my_broken_local_repo" e adicioná-los ao git. Depois de ter certeza de que seu novo repositório local tem tudo o que você precisa, é possível excluir "my_broken_local_repo".

Se você quiser apenas jogar fora as confirmações locais e manter as modificações feitas nos arquivos,
git reset @ ~
Outras respostas abordaram a reinicialização completa