Entenda o ciclo de vida dos arquivos no Git e facilite seu trabalho

Git é um versionador de código fonte fácil de usar, isso quase todos sabem, entretanto sua experiência de uso pode ser bem confusa em alguns casos. Convido-os a uma breve explanação sobre o ciclo de vida dos arquivos no Git, que certamente irá agregar em seu dia a dia.

Muitos seguem suas vidas normalmente com a sequência pull > modificação > commit > push, de fato, muito do seu dia-a-dia será praticamente isso, porém, nem sempre tudo ocorre como esperamos e saímos um pouco do comum quando, por exemplo, esquecemos de adicionar algo no commit, ou quando queremos desfazer algo, e até mesmo em um merge que alterou tantos lugares diferentes que dói a cabeça só de pensar.

Quantas vezes já ficou um bom tempo debruçado no micro tentando desfazer algo sem perder o trabalho de horas? Quantas vezes ficou procurando no Google por comandos salvadores que revertesse tudo como passe de mágica? Quantas vezes decidiu que a única solução era clonar de novo o repositório e refazer tudo?

Pode nunca ter acontecido com você, mas acontece com bastante gente e, em muitos dos casos, o motivo é simples falta de compreensão do ciclo de vida dos arquivos.

Estados dos arquivos no git

Os arquivos no Git sempre se encontram em algum estado: untracked, unmodified, modified e stage. Entender esses estados nos ajuda a saber melhor qual o momento certo de usar cada comando.

Untracked

Arquivos marcados como untracked são arquivos não monitorados pelo Git. Os arquivos que acabaram de ser criados sempre estarão com esse estado. Vamos criar um arquivo chamado arq01 e usar o comando git status para verificar o que ocorreu no repositório:

 git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git git

$ touch arq01
$ git status arq01
No ramo master
Submissão inicial.

Arquivos não monitorados: (utilize git add <arquivo> para incluir o que será submetido)

Para que o Git comece a versionar o arquivo precisamos mudá-lo para stage. Note que o Git sempre vai te dar a dica do que fazer quando executar o git status:

$ git add arq01
$ git status
No ramo master
Submissão inicial.

Mudanças a serem submetidas:
(utilize “git rm –cached <arquivo>…” para não apresentar)

new file: arq01

Como podemos ver, o estado do arquivo mudou. O Git já o reconhece e ele está pronto para ser salvo.

Stage

Os arquivos marcados como stage são os arquivos novos ou modificados que serão salvos no próximo commit. O que o comando anterior git add faz é adicionar os arquivos de untracked e modified para stage.

Precisamos agora dar o comando git commit para salvar a nova versão do repositório:

$ git commit -m ‘Meu primeiro commit’

[master (root-commit) 2003295] Meu primeiro commit

1 file changed, 0 insertions(+), 0 deletions(-)

create mode 100644 arq01

Unmodified

Quando realizamos um commit, os arquivos saem de stage para unmodified, isso significa que, na linha do tempo, seu arquivo está igual ao estado salvo no último commit.

No commit, salvamos o estado do repositório e o Git passa a informar das mudanças do último commit (HEAD) em diante.

$ git status

No ramo master

nada a submeter, diretório de trabalho vazio

Modified

São os arquivos já monitorados pelo Git que sofreram alguma alteração desde o último commit:

$ echo ‘uma linha’ >> arq01

$ git status

No ramo master

Changes not staged for commit:

(utilize “git add <arquivo>…” para atualizar o que será submetido)

(utilize “git checkout — <arquivo>…” para descartar mudanças no diretório de trabalho)

modified: arq01

Se quisermos salvar a alteração, basta mudar o arquivo para a área de stage com o comando git add e depois git commit para gerar a nova versão com as mudanças:

$ git add arq01

$ git status

No ramo master

Mudanças a serem submetidas:

(use “git reset HEAD <file>…” to unstage)

modified: arq01

$ git commit -m ‘Nova mudança’

[master fd009e0] Nova mudança

1 file changed, 1 insertion(+)

Desfazendo as coisas

Agora que entendemos melhor os estados, podemos entender como reverter cada um deles.

Seguindo na ordem anterior, para desfazer um arquivo untracked você precisa apenas remover o arquivo. Como ele ainda não foi adicionado no Git, caso seja removido ele não sentirá falta.

Depois, caso tenha adicionado o arquivo novo em stage e queira remover ele de lá, basta utilizar o comando git reset HEAD <filename>. Este comando retornará o arquivo de stage para untracked (caso seja um arquivo novo) ou modified (caso seja um arquivo que já existia mas foi modificado).

$ echo “Segunda linha” >> arq01

$ git add arq01

$ git status

No ramo master

Mudanças a serem submetidas:

(use “git reset HEAD <file>…” to unstage)

modified: arq01

$ git reset HEAD arq01

Unstaged changes after reset:

M arq01

$ git status

No ramo master

Changes not staged for commit:

(utilize “git add <arquivo>…” para atualizar o que será submetido)

(utilize “git checkout — <arquivo>…” para descartar mudanças no diretório de trabalho)

modified: arq01

Se observarmos, no último git status já temos uma dica do Git como retornar arquivos de modified para unmodified: git checkout <filename>:

gabriel@Bilbo:/tmp/git$ git checkout arq01

gabriel@Bilbo:/tmp/git$ git status

No ramo master

nada a submeter, diretório de trabalho vazio

Esse comando retornará o arquivo para a versão do último commit. Cuidado com ele, você pode perder todo o trabalho realizado.

Por último, mas não menos importante, podemos também remover ou desfazer os commits, mantendo ou não o histórico do que já foi feito.

Para remover o commit faça:

$ git reset HEAD~1

Cada número que colocar depois do HEAD é um commit que quer remover. Neste caso estamos removendo um commit para trás. Poderia ser quantos quisesse ou quantos estivessem disponíveis. Quando executamos esse comando, as alterações vão todas para modified. Você pode alterar algo específico e dar o commit de novo ou remover todas as mudanças com o git checkout.

Acredito que agora, entendendo melhor cada um dos estados dos arquivos, fica muito mais fácil resolver problemas no Git quando eles aparecerem.