Oiê! Tudo certo por aí?
O git checkout -- [file]
desfaz modificações que ainda não foram adicionadas ao stage (etapa de preparação para commitar uma mudança), o que significa dizer que o comando git add
ainda não foi executado.
Enquanto o comando visto anteriormente lida com arquivos, o git reset --hard
, por outro lado, trabalha com os commits do nosso projeto. Por meio dele, retornamos a um ponto específico do nosso histórico e, consequentemente, ocorre a perda de todos os commits feitos ao longo desse caminho. Por esse motivo, git reset --hard
é perigoso e, se possível, deve ser evitado.
Abaixo há um exemplo ilustrativo disso:
Note que, depois de realizar git reset --hard
para o hash 8a4fc73 (número gerado aleatoriamente para servir de referência ao commit), os dois commits mais a direita estão diferentes, com um tracejado em volta e sem coloração, indicando que não existem mais.
Caso o objetivo fosse usar o comando git reset
em um arquivo, o parâmetro --hard
não precisaria ser adicionado e a ideia continuaria sendo a mesma: ao digitar git add
, seria usado o git reset
para retirar a mudança feita do stage.
Com isso, percebemos que, embora semelhantes, git checkout
e git reset
possuem diferenças, cuja principal é que no primeiro caso a modificação ainda não foi adicionada ao stage (através do git add
), ao passo que no segundo, foi.
Espero que tenha compreendido minha explicação! Fico à disposição para te ajudar no que for preciso!
Grande abraço e até mais!
Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓.