2.2 Fundamentos do Git - Gravando Alterações no Repositório

A principal ferramenta que você usa para determinar quais arquivos estão em qual estado é o comando git status. Se você executar este comando logo após um clone, deverá ver algo assim:

Isso significa que você tem um diretório de trabalho limpo; em outras palavras, nenhum dos seus arquivos rastreados foi modificado. O Git também não vê nenhum arquivo não rastreado, ou eles estariam listados aqui. Por fim, o comando informa em qual branch você está e informa que não divergiu do mesmo branch no servidor. Por enquanto, esse branch é sempre master, que é o padrão; você não vai se preocupar com isso aqui. Ramificação (Branching) no Git abordará branches e referências em detalhes.

Digamos que você adicione um novo arquivo ao seu projeto, um arquivo README simples. Se o arquivo não existia antes e você executar git status, verá seu arquivo não rastreado assim:

Você pode ver que seu novo arquivo README não é rastreado, porque está sob o cabeçalho “Untracked files” na saída do status. Não rastreado basicamente significa que o Git vê um arquivo que você não tinha no snapshot anterior (commit) e que ainda não foi preparado; o Git não começará a incluí-lo em seus snapshots de commit até que você diga explicitamente a ele para fazer isso. Ele faz isso para que você não comece acidentalmente a incluir arquivos binários gerados ou outros arquivos que você não pretendia incluir. Você quer começar a incluir o README, então vamos começar a rastrear o arquivo.

Para começar a rastrear um novo arquivo, você usa o comando git add. Para começar a rastrear o arquivo README, você pode executar isto:

Se você executar seu comando status novamente, poderá ver que seu arquivo README agora está rastreado e preparado para ser commitado:

Você pode dizer que ele está preparado porque está sob o cabeçalho “Changes to be committed”. Se você fizer o commit neste ponto, a versão do arquivo no momento em que você executou o git add é a que estará no snapshot histórico subsequente. Você deve se lembrar que, quando executou o git init anteriormente, executou o git add <arquivos> em seguida — isso foi para começar a rastrear arquivos no seu diretório. O comando git add recebe um nome de caminho para um arquivo ou diretório; se for um diretório, o comando adiciona todos os arquivos desse diretório recursivamente.

Vamos alterar um arquivo que já estava rastreado. Se você alterar um arquivo previamente rastreado chamado CONTRIBUTING.md e depois executar seu comando git status novamente, obterá algo parecido com isto:

O arquivo CONTRIBUTING.md aparece em uma seção chamada “Changes not staged for commit” — o que significa que um arquivo que é rastreado foi modificado no diretório de trabalho, mas ainda não foi preparado. Para prepará-lo, você executa o comando git add. git add é um comando polivalente — você o usa para começar a rastrear novos arquivos, preparar arquivos e fazer outras coisas como marcar arquivos com conflito de mesclagem (merge-conflicted files) como resolvidos. Pode ser útil pensar nele mais como “adicione precisamente este conteúdo ao próximo commit” em vez de “adicione este arquivo ao projeto”. Vamos executar git add agora para preparar o arquivo CONTRIBUTING.md e depois executar git status novamente:

Ambos os arquivos estão preparados e irão para o seu próximo commit. Neste ponto, suponha que você se lembre de uma pequena alteração que deseja fazer no CONTRIBUTING.md antes de fazer o commit dele. Você o abre novamente e faz essa alteração, e está pronto para fazer o commit. No entanto, vamos executar git status mais uma vez:

Que diabos? Agora o CONTRIBUTING.md está listado como preparado e não preparado. Como isso é possível? Acontece que o Git prepara um arquivo exatamente como ele é quando você executa o comando git add. Se você fizer o commit agora, a versão de CONTRIBUTING.md como era quando você executou o comando git add pela última vez é como ela entrará no commit, não a versão do arquivo como aparece no seu diretório de trabalho quando você executa git commit. Se você modificar um arquivo depois de executar git add, precisará executar git add novamente para preparar a versão mais recente do arquivo:

Embora a saída de git status seja bem abrangente, ela também é bastante prolixa. O Git também tem uma flag de status curto (short status) para que você possa ver suas alterações de uma maneira mais compacta. Se você executar git status -s ou git status --short, obterá uma saída muito mais simplificada do comando:

Arquivos novos que não são rastreados têm um ?? ao lado deles, arquivos novos que foram adicionados à área de preparação têm um A, arquivos modificados têm um M e assim por diante. Existem duas colunas na saída — a coluna da esquerda indica o status da área de preparação e a coluna da direita indica o status da árvore de trabalho (working tree). Portanto, por exemplo nessa saída, o arquivo README foi modificado no diretório de trabalho, mas ainda não foi preparado, enquanto o arquivo lib/simplegit.rb foi modificado e preparado. O Rakefile foi modificado, preparado e modificado novamente, portanto, há alterações nele que estão preparadas e não preparadas.

Geralmente, você terá uma classe de arquivos que não deseja que o Git adicione automaticamente ou até mesmo mostre a você como não rastreados. Estes geralmente são arquivos gerados automaticamente, como arquivos de log ou arquivos produzidos pelo seu sistema de compilação (build system). Nesses casos, você pode criar um arquivo listando padrões que correspondam a eles, chamado .gitignore. Aqui está um exemplo de arquivo .gitignore:

A primeira linha diz ao Git para ignorar quaisquer arquivos que terminem em “.o” ou “.a” — arquivos de objeto e de arquivamento (archive) que podem ser o produto da compilação do seu código. A segunda linha diz ao Git para ignorar todos os arquivos cujos nomes terminam com um til (~), o que é usado por muitos editores de texto como o Emacs para marcar arquivos temporários. Você também pode incluir um diretório de log, tmp ou pid; documentação gerada automaticamente; e assim por diante. Configurar um arquivo .gitignore para o seu novo repositório antes de começar é geralmente uma boa ideia, para que você não faça o commit acidentalmente de arquivos que você realmente não deseja em seu repositório Git.

As regras para os padrões que você pode colocar no arquivo .gitignore são as seguintes:

Os padrões de glob são como expressões regulares simplificadas que os shells usam. Um asterisco (*) corresponde a zero ou mais caracteres; [abc] corresponde a qualquer caractere dentro dos colchetes (neste caso, a, b ou c); um ponto de interrogação (?) corresponde a um único caractere; e os caracteres dentro de colchetes separados por um hífen ([0-9]) correspondem a qualquer caractere entre eles (neste caso, de 0 a 9). Você também pode usar dois asteriscos para corresponder a diretórios aninhados; a/**/z corresponderia a a/z, a/b/z, a/b/c/z e assim por diante.

Aqui está outro exemplo de arquivo .gitignore:

Se o comando git status for muito vago para você — você quer saber exatamente o que você alterou, não apenas quais arquivos foram alterados — você pode usar o comando git diff. Abordaremos o git diff com mais detalhes posteriormente, mas você provavelmente o usará com mais frequência para responder a estas duas perguntas: O que você alterou, mas ainda não preparou? E o que você preparou que está prestes a fazer o commit? Embora git status responda a essas perguntas de maneira muito geral, listando os nomes dos arquivos, git diff mostra as linhas exatas adicionadas e removidas — o patch, por assim dizer.

Digamos que você edite e prepare o arquivo README novamente e, em seguida, edite o arquivo CONTRIBUTING.md sem prepará-lo. Se você executar seu comando git status, verá mais uma vez algo assim:

Para ver o que você alterou, mas ainda não preparou, digite git diff sem outros argumentos:

Esse comando compara o que está no seu diretório de trabalho com o que está na sua área de preparação. O resultado informa as alterações que você fez e que ainda não preparou.

Se você quiser ver o que você preparou e que irá para o seu próximo commit, pode usar git diff --staged. Este comando compara suas alterações preparadas com o seu último commit:

É importante notar que git diff por si só não mostra todas as alterações feitas desde o seu último commit — apenas as alterações que ainda não foram preparadas. Se você tiver preparado todas as suas alterações, o git diff não fornecerá nenhuma saída.

Como outro exemplo, se você preparar o arquivo CONTRIBUTING.md e depois editá-lo, poderá usar git diff para ver as alterações no arquivo que estão preparadas e as alterações que não estão preparadas. Se o nosso ambiente for assim:

Agora você pode usar git diff para ver o que ainda não foi preparado:

e git diff --cached para ver o que você preparou até agora (--staged e --cached são sinônimos):

Agora que sua área de preparação está configurada do jeito que você deseja, você pode fazer o commit de suas alterações. Lembre-se de que qualquer coisa que ainda não esteja preparada — quaisquer arquivos que você criou ou modificou e nos quais não executou git add desde que os editou — não entrará neste commit. Eles permanecerão como arquivos modificados no seu disco. Neste caso, digamos que da última vez que você executou git status, viu que tudo estava preparado, então você está pronto para fazer o commit das suas alterações. A maneira mais simples de fazer o commit é digitar git commit:

Isso inicia o seu editor de escolha.

O editor exibe o seguinte texto (este exemplo é uma tela do Vim):

Você pode ver que a mensagem de commit padrão contém a saída mais recente do comando git status comentada e uma linha vazia no topo. Você pode remover esses comentários e digitar sua mensagem de commit, ou pode deixá-los lá para ajudá-lo a lembrar o que está commitando.

Quando você sai do editor, o Git cria o seu commit com essa mensagem de commit (com os comentários e o diff removidos).

Alternativamente, você pode digitar sua mensagem de commit embutida no comando commit especificando-a após a flag -m, assim:

Agora você criou o seu primeiro commit! Você pode ver que o commit forneceu a você algumas saídas sobre si mesmo: em qual branch você fez o commit (master), qual checksum SHA-1 o commit tem (463dc4f), quantos arquivos foram alterados e estatísticas sobre as linhas adicionadas e removidas no commit.

Lembre-se de que o commit registra o snapshot que você configurou na sua área de preparação. Qualquer coisa que você não tenha preparado ainda está lá modificada; você pode fazer outro commit para adicioná-la ao seu histórico. Toda vez que você realiza um commit, está registrando um snapshot do seu projeto para o qual você pode reverter ou comparar posteriormente.

Embora possa ser incrivelmente útil para criar commits exatamente da forma como você os deseja, a área de preparação às vezes é um pouco mais complexa do que você precisa em seu fluxo de trabalho. Se você quiser pular a área de preparação, o Git fornece um atalho simples. Adicionar a opção -a ao comando git commit faz com que o Git prepare automaticamente todos os arquivos que já estão sendo rastreados antes de fazer o commit, permitindo que você ignore a parte do git add:

Observe como você não precisa executar git add no arquivo CONTRIBUTING.md neste caso antes de fazer o commit. Isso ocorre porque a flag -a inclui todos os arquivos alterados. Isso é conveniente, mas tenha cuidado; às vezes, essa flag fará com que você inclua alterações indesejadas.

Para remover um arquivo do Git, você deve removê-lo dos seus arquivos rastreados (mais precisamente, removê-lo da sua área de preparação) e, em seguida, fazer o commit. O comando git rm faz isso e também remove o arquivo do seu diretório de trabalho para que você não o veja como um arquivo não rastreado na próxima vez.

Se você simplesmente remover o arquivo do seu diretório de trabalho, ele aparecerá na área “Changes not staged for commit” (ou seja, não preparado) da saída do seu git status:

Então, se você executar git rm, ele preparará a remoção do arquivo:

Na próxima vez que você fizer commit, o arquivo não existirá mais e não será mais rastreado. Se você modificou o arquivo ou já o adicionou à área de preparação, deve forçar a remoção com a opção -f. Esse é um recurso de segurança para evitar a remoção acidental de dados que ainda não foram gravados em um snapshot e que não podem ser recuperados do Git.

Outra coisa útil que você pode querer fazer é manter o arquivo na sua árvore de trabalho, mas removê-lo da sua área de preparação. Em outras palavras, você pode querer manter o arquivo no seu disco rígido, mas não ter mais o Git o rastreando. Isso é particularmente útil se você esqueceu de adicionar algo ao seu arquivo .gitignore e acidentalmente o preparou, como um arquivo de log grande ou um monte de arquivos .a compilados. Para fazer isso, use a opção --cached:

Você pode passar arquivos, diretórios e padrões de file-glob para o comando git rm. Isso significa que você pode fazer coisas como:

Observe a barra invertida (\) na frente do *. Isso é necessário porque o Git faz sua própria expansão de nome de arquivo, além da expansão de nome de arquivo do seu shell. Esse comando remove todos os arquivos que têm a extensão .log no diretório log/. Ou você pode fazer algo assim:

Este comando remove todos os arquivos cujos nomes terminam com um ~.

Ao contrário de muitos outros VCSs, o Git não rastreia explicitamente o movimento de arquivos. Se você renomear um arquivo no Git, nenhum metadado será armazenado no Git que informe que você renomeou o arquivo. No entanto, o Git é muito inteligente em descobrir isso depois do fato — lidaremos com a detecção de movimento de arquivos um pouco mais tarde.

Portanto, é um pouco confuso que o Git tenha um comando mv. Se você quiser renomear um arquivo no Git, você pode executar algo como:

e funciona perfeitamente. De fato, se você executar algo assim e observar o status, verá que o Git o considera um arquivo renomeado:

No entanto, isso é equivalente a executar algo assim:

O Git descobre que é uma renomeação implicitamente, portanto, não importa se você renomeia um arquivo dessa maneira ou com o comando mv. A única diferença real é que git mv é um comando em vez de três — é uma função de conveniência. Mais importante ainda, você pode usar qualquer ferramenta que desejar para renomear um arquivo e tratar o add/rm depois, antes de fazer o commit.