Chapters ā–¾ 2nd Edition

2.4 Fundamentos de Git - Desfazendo coisas

Desfazendo coisas

Em qualquer estĆ”gio, vocĆŖ talvez queira desfazer algo. Aqui, vamos rever algumas ferramentas bĆ”sicas para desfazer modificaƧƵes que porventura tenha feito. Seja cuidadoso, porque nem sempre vocĆŖ pode voltar uma alteraĆ§Ć£o desfeita. Essa Ć© uma das poucas Ć”reas do Git onde pode perder algum trabalho feito se vocĆŖ cometer algum engano.

Um dos motivos mais comuns para desfazer um comando, aparece quando vocĆŖ executa um commit muito cedo e possivelmente esquecendo de adicionar alguns arquivos ou vocĆŖ escreveu a mensagem do commit de forma equivocada. Se vocĆŖ quiser refazer este commit, execute o commit novamente usando a opĆ§Ć£o --amend:

$ git commit --amend

Esse comando pega a Ć”rea stage e a usa para realizar o commit. Se vocĆŖ nĆ£o fez nenhuma alteraĆ§Ć£o desde o Ćŗltimo commit (por exemplo, se vocĆŖ executar o comando imediatamente depois do commit anterior), entĆ£o sua imagem dos arquivos irĆ” ser exatamente a mesma, e tudo o que vocĆŖ alterarĆ” serĆ” a mensagem do commit.

O mesmo editor de mensagens de commit Ć© acionado, porĆ©m o commit anterior jĆ” possui uma mensagem. VocĆŖ pode editar a mensagem como sempre, porĆ©m esta sobrescreve a mensagem do commit anterior.

Por exemplo, se vocĆŖ fizer um commit e entĆ£o lembrar que esqueceu de colocar no stage as modificaƧƵes de um arquivo que vocĆŖ quer adicionar no commit, vocĆŖ pode fazer algo semelhante a isto:

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

No final das contas vocĆŖ termina com um Ćŗnico commit ā€“ O segundo commit substitui o resultante do primeiro.

Retirando um arquivo do Stage

A prĆ³xima sessĆ£o demonstra como trabalhar com modificaƧƵes na Ć”rea stage e work directory. A boa notĆ­cia Ć© que o comando que vocĆŖ usa para verificar o estado dessas duas Ć”reas, tambĆ©m te relembra como desfazer as modificaƧƵes aplicadas. Por exemplo, vamos supor que vocĆŖ alterou dois arquivos, e deseja realizar o commit deles separadamente, porĆ©m vocĆŖ acidentalmente digitou git add * adicionando ambos ao stage. Como vocĆŖ pode retirar um deles do stage? O comando git status lhe lembrarĆ” de como fazer isso:

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

Logo abaixo do texto ā€œChanges to be committedā€, diz git reset HEAD <file>... para retirar o arquivo do stage. EntĆ£o, vamos usar esta sugestĆ£o para retirar o arquivo CONTRIBUTING.md do stage:

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

O comando Ć© um tanto quanto estranho, mas funciona. O arquivo CONTRIBUTING.md volta ao estado modificado porem estĆ” novamente fora do stage.

Note

Ɖ verdade que o comando git reset pode ser perigoso, especialmente se vocĆŖ usar a opĆ§Ć£o --hard. Entretanto, no cenĆ”rio descrito acima, o arquivo no working directory estĆ” inalterado, entĆ£o Ć© relativamente seguro utilizar o comando.

Essa mĆ”gica usando o git reset Ć© tudo que vocĆŖ precisa saber por enquanto sobre este comando. NĆ³s vamos entra mais no detalhe sobre o que o comando reset faz e como usĆ”-lo de forma a fazer coisas realmente interessantes em Reset Demystified.

Desfazendo as ModificaƧƵes de um Arquivo

E se vocĆŖ se der conta de que na verdade nĆ£o quer manter as modificaƧƵes do arquivo CONTRIBUTING.md? Como vocĆŖ pode reverter as modificaƧƵes, voltando a ser como era quando foi realizado o Ćŗltimo commit (ou clone inicial, ou seja como for que vocĆŖ chegou ao seu working directory)? Felizmente, git status diz a vocĆŖ como fazer isso tambĆ©m. Neste Ćŗltimo exemplo, a Ć”rea fora do stage parece com isso:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Isso lhe diz de forma explicita como descartar as modificaƧƵes que vocĆŖ fez. Vamos fazer o que o comando nos sugeriu:

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

VocĆŖ pode notar que as modificaƧƵes foram revertidas.

Important

Ɖ importante entender que o git checkout -- <file> Ć© um a comando perigoso. Qualquer modificaĆ§Ć£o que vocĆŖ fez no arquivo se foiā€‰ā€”ā€‰O Git apenas substitui o arquivo pela Ćŗltima versĆ£o (mais recente) que sofreu commit. Nunca use este comando a nĆ£o ser que vocĆŖ saiba com certeza que nĆ£o quer salvar as modificaƧƵes do arquivo.

Se vocĆŖ gostaria de manter as modificaƧƵes que fez no arquivo, porem precisa tirĆ”-lo do caminho por enquanto, sugerimos que pule para a documentaĆ§Ć£o sobre Branches[ch03-git-branching]; esta geralmente Ć© a melhor forma de fazer isso.

Lembre-se, qualquer coisa que sobre commit com Git pode quase sempre ser recuperada. AtĆ© mesmo commits que estava em algum branches que foram deletados ou commits que forma sobre escritos atravĆ©s de um --amend podem ser recuperados (vejaData Recovery para recuperaĆ§Ć£o de dados). Contudo, qualquer coisa que vocĆŖ perder que nunca sofreu commit pode ser considerada praticamente perdida.

scroll-to-top