7.7 Ferramentas do Git - Reset Desmistificado

Uma maneira mais fácil de pensar sobre reset e checkout é através do modelo mental de que o Git é um gerenciador de conteúdo de três árvores diferentes. Por “árvore” aqui, queremos dizer realmente “coleção de arquivos”, não especificamente a estrutura de dados. Há alguns casos em que o index não age exatamente como uma árvore, mas para nossos propósitos é mais fácil pensar sobre ele dessa forma por enquanto.

O Git, como sistema, gerencia e manipula três árvores em sua operação normal:

O fluxo de trabalho típico do Git é gravar snapshots do seu projeto em estados sucessivamente melhores, manipulando essas três árvores.

Vamos visualizar esse processo: digamos que você entre num diretório novo com um único arquivo nele. Chamaremos esta de v1 do arquivo, e a indicaremos em azul. Agora nós rodamos git init, o que criará um repositório Git com uma referência HEAD que aponta para a branch master não nascida (unborn).

Neste ponto, apenas a árvore do diretório de trabalho tem algum conteúdo.

Agora queremos comitar este arquivo, então usamos git add para pegar o conteúdo do diretório de trabalho e copiá-lo para o index.

Então nós rodamos git commit, o que pega o conteúdo do index e o salva como um snapshot permanente, cria um objeto de commit que aponta para esse snapshot, e atualiza a master para apontar para esse commit.

Se rodarmos git status, não veremos alterações, porque todas as três árvores são as mesmas.

Agora queremos fazer uma alteração nesse arquivo e comitá-lo. Passaremos pelo mesmo processo; primeiro, nós alteramos o arquivo no nosso diretório de trabalho. Vamos chamar isso de v2 do arquivo, e indicá-la em vermelho.

Se rodarmos git status agora, veremos o arquivo em vermelho como “Changes not staged for commit” (Alterações não preparadas para commit), porque essa entrada difere entre o index e o diretório de trabalho. Em seguida, nós rodamos git add nele para prepará-lo (stage) no nosso index.

Neste ponto, se rodarmos git status, veremos o arquivo em verde sob “Changes to be committed” (Alterações a serem comitadas) porque o index e o HEAD diferem — isto é, o nosso próximo commit proposto é agora diferente do nosso último commit. Finalmente, nós rodamos git commit para finalizar o commit.

Agora, git status não nos dará nenhuma saída, porque todas as três árvores estão iguais novamente.

Trocar de branch ou clonar passa por um processo semelhante. Quando você faz checkout num branch, isso altera o HEAD para apontar para a nova ref de branch, popula o seu index com o snapshot desse commit, e então copia o conteúdo do index para o seu diretório de trabalho.

O comando reset faz mais sentido quando visto neste contexto.

Para os propósitos destes exemplos, digamos que nós modificamos file.txt novamente e o comitamos uma terceira vez. Então agora nosso histórico está assim:

Vamos agora percorrer exatamente o que o reset faz quando você o chama. Ele manipula diretamente estas três árvores de uma forma simples e previsível. Ele faz até três operações básicas.

Isso cobre o comportamento do reset em sua forma básica, mas você também pode fornecer a ele um caminho (path) para agir sobre. Se você especificar um caminho, o reset pulará o passo 1 e limitará o restante de suas ações a um arquivo ou conjunto de arquivos específico. Isso até que faz sentido — o HEAD é apenas um ponteiro, e você não pode apontar para parte de um commit e parte de outro. Mas o index e o diretório de trabalho podem ser parcialmente atualizados, então o reset prossegue com os passos 2 e 3.

Então, assuma que rodamos git reset file.txt. Esta forma (já que você não especificou um SHA-1 de commit ou branch, e não especificou --soft ou --hard) é um atalho para git reset --mixed HEAD file.txt, o qual irá:

Então, essencialmente, ele apenas copia o file.txt do HEAD para o index.

Isso tem o efeito prático de tirar o arquivo do stage (unstaging). Se olharmos para o diagrama desse comando e pensarmos sobre o que o git add faz, eles são exatamente o oposto.

É por isso que a saída do comando git status sugere que você rode isto para tirar um arquivo do stage (veja Retirando a Preparação de um Arquivo Preparado (Unstaging) para mais informações sobre isso).

Poderíamos facilmente não deixar o Git assumir que queríamos dizer “pegue os dados do HEAD” especificando um commit específico para puxar (pull) aquela versão do arquivo. Nós apenas rodaríamos algo como git reset eb43bf file.txt.

Isso efetivamente faz a mesma coisa como se tivéssemos revertido o conteúdo do arquivo para v1 no diretório de trabalho, rodado git add nele, e então revertido de volta para v3 novamente (sem realmente passar por todos esses passos). Se rodarmos git commit agora, ele registrará uma alteração que reverte esse arquivo de volta para v1, mesmo que nunca o tenhamos realmente tido no nosso diretório de trabalho novamente.

Também é interessante notar que, assim como o git add, o comando reset aceitará a opção --patch para remover partes do conteúdo do stage trecho por trecho (hunk-by-hunk). Assim, você pode remover do stage ou reverter conteúdos seletivamente.

Vamos olhar como fazer algo interessante com este poder recém-descoberto — juntar (squashing) commits.

Digamos que você tenha uma série de commits com mensagens como “oops.”, “WIP” (work in progress) e “forgot this file” (esqueci desse arquivo). Você pode usar o reset para juntá-los rápida e facilmente em um único commit que faz você parecer muito esperto. A seção Juntando Commits (Squashing) mostra outra maneira de fazer isso, mas neste exemplo é mais simples usar o reset.

Digamos que você tenha um projeto onde o primeiro commit tem um arquivo, o segundo commit adicionou um novo arquivo e alterou o primeiro, e o terceiro commit alterou o primeiro arquivo novamente. O segundo commit foi um trabalho em andamento e você quer juntá-lo.

Você pode rodar git reset --soft HEAD~2 para mover a branch HEAD de volta para um commit mais antigo (o commit mais recente que você quer manter):

E então simplesmente rodar git commit novamente:

Agora você pode ver que o seu histórico alcançável, o histórico que você faria push, agora parece que você teve um commit com file-a.txt v1, então um segundo que modificou file-a.txt para v3 e adicionou file-b.txt. O commit com a versão v2 do arquivo não está mais no histórico.

Finalmente, você pode se perguntar qual é a diferença entre checkout e reset. Assim como o reset, o checkout manipula as três árvores, e é um pouco diferente dependendo se você passa um caminho de arquivo para o comando ou não.

Esperamos que agora você entenda e se sinta mais confortável com o comando reset, mas provavelmente ainda esteja um pouco confuso sobre como exatamente ele difere do checkout e não consiga se lembrar de todas as regras das diferentes invocações.

Aqui está uma folha de dicas (cheat-sheet) sobre quais comandos afetam quais árvores. A coluna “HEAD” lê “REF” se o comando mover a referência (branch) para a qual o HEAD aponta, e “HEAD” se ele mover o próprio HEAD. Preste atenção especial à coluna 'WD Seguro?' — se disser NÃO, reserve um segundo para pensar antes de rodar o comando.