1.3 Primeiros Passos - O que é Git?

A principal diferença entre o Git e qualquer outro VCS (Subversion e amigos incluídos) é a maneira como o Git pensa sobre seus dados. Conceitualmente, a maioria dos outros sistemas armazena informações como uma lista de alterações baseadas em arquivos. Esses outros sistemas (CVS, Subversion, Perforce e assim por diante) pensam nas informações que armazenam como um conjunto de arquivos e as alterações feitas em cada arquivo ao longo do tempo (isso é comumente descrito como controle de versão baseado em delta).

O Git não pensa ou armazena seus dados dessa maneira. Em vez disso, o Git pensa em seus dados mais como uma série de snapshots de um sistema de arquivos em miniatura. Com o Git, toda vez que você faz um commit, ou salva o estado do seu projeto, o Git basicamente tira uma foto de como todos os seus arquivos se parecem naquele momento e armazena uma referência para esse snapshot. Para ser eficiente, se os arquivos não mudaram, o Git não armazena o arquivo novamente, apenas um link para o arquivo idêntico anterior que ele já armazenou. O Git pensa em seus dados mais como um fluxo de snapshots.

Esta é uma distinção importante entre o Git e quase todos os outros VCSs. Isso faz com que o Git reconsidere quase todos os aspectos do controle de versão que a maioria dos outros sistemas copiou da geração anterior. Isso torna o Git mais como um mini sistema de arquivos com algumas ferramentas incrivelmente poderosas construídas sobre ele, em vez de simplesmente um VCS. Exploraremos alguns dos benefícios que você ganha ao pensar em seus dados dessa maneira quando abordarmos o branching do Git em Ramificação (Branching) no Git.

A maioria das operações no Git precisa apenas de arquivos e recursos locais para operar — geralmente nenhuma informação de outro computador na sua rede é necessária. Se você está acostumado a um CVCS em que a maioria das operações tem aquele custo adicional de latência de rede, esse aspecto do Git fará você pensar que os deuses da velocidade abençoaram o Git com poderes de outro mundo. Como você tem todo o histórico do projeto bem ali no seu disco local, a maioria das operações parece quase instantânea.

Por exemplo, para navegar no histórico do projeto, o Git não precisa ir ao servidor para obter o histórico e exibi-lo para você — ele simplesmente o lê direto do seu banco de dados local. Isso significa que você vê o histórico do projeto quase instantaneamente. Se você quiser ver as alterações introduzidas entre a versão atual de um arquivo e o arquivo há um mês, o Git pode consultar o arquivo de um mês atrás e fazer um cálculo de diferença local, em vez de ter que pedir a um servidor remoto para fazer isso ou extrair uma versão mais antiga do arquivo do servidor remoto para fazê-lo localmente.

Isso também significa que há muito pouco que você não pode fazer se estiver offline ou fora da VPN. Se você entrar em um avião ou trem e quiser trabalhar um pouco, pode fazer commits alegremente (na sua cópia local, lembra?) até chegar a uma conexão de rede para fazer o upload. Se você for para casa e não conseguir fazer o seu cliente VPN funcionar corretamente, você ainda pode trabalhar. Em muitos outros sistemas, fazer isso é impossível ou doloroso. No Perforce, por exemplo, você não pode fazer muita coisa quando não está conectado ao servidor; no Subversion e CVS, você pode editar arquivos, mas não pode fazer commit das alterações no seu banco de dados (porque o seu banco de dados está offline). Isso pode não parecer grande coisa, mas você pode se surpreender com a grande diferença que isso pode fazer.

Tudo no Git é verificado por soma de verificação (checksummed) antes de ser armazenado e é então referido por essa soma de verificação. Isso significa que é impossível alterar o conteúdo de qualquer arquivo ou diretório sem que o Git saiba disso. Essa funcionalidade é incorporada ao Git nos níveis mais baixos e é essencial à sua filosofia. Você não pode perder informações em trânsito ou sofrer corrupção de arquivos sem que o Git seja capaz de detectar isso.

O mecanismo que o Git usa para essa soma de verificação é chamado de hash SHA-1. Esta é uma string de 40 caracteres composta por caracteres hexadecimais (0–9 e a–f) e calculada com base no conteúdo de um arquivo ou estrutura de diretórios no Git. Um hash SHA-1 se parece com isto:

Você verá esses valores de hash em todos os lugares no Git porque ele os usa muito. Na verdade, o Git armazena tudo em seu banco de dados não pelo nome do arquivo, mas pelo valor de hash do seu conteúdo.

Quando você executa ações no Git, quase todas elas apenas adicionam dados ao banco de dados do Git. É difícil fazer o sistema fazer qualquer coisa que não seja desfazível ou fazê-lo apagar dados de alguma forma. Como com qualquer VCS, você pode perder ou bagunçar alterações que ainda não commitou, mas depois que você faz o commit de um snapshot no Git, é muito difícil perdê-lo, especialmente se você envia (push) regularmente o seu banco de dados para outro repositório.

Isso faz com que usar o Git seja uma alegria, porque sabemos que podemos experimentar sem o perigo de estragar as coisas gravemente. Para uma visão mais aprofundada de como o Git armazena seus dados e como você pode recuperar dados que parecem perdidos, veja Desfazendo Coisas.

Preste atenção agora — aqui está a principal coisa a lembrar sobre o Git se você quiser que o resto do seu processo de aprendizado ocorra sem problemas. O Git tem três estados principais nos quais seus arquivos podem residir: modificado, preparado e commitado:

Isso nos leva às três seções principais de um projeto Git: a árvore de trabalho, a área de preparação e o diretório Git.

A árvore de trabalho é um único checkout de uma versão do projeto. Esses arquivos são retirados do banco de dados compactado no diretório Git e colocados no disco para você usar ou modificar.

A área de preparação é um arquivo, geralmente contido no seu diretório Git, que armazena informações sobre o que irá para o seu próximo commit. Seu nome técnico no jargão do Git é o “index”, mas a frase “área de preparação” funciona da mesma forma.

O diretório Git é onde o Git armazena os metadados e o banco de dados de objetos para o seu projeto. Esta é a parte mais importante do Git e é o que é copiado quando você clona um repositório de outro computador.

O fluxo de trabalho básico do Git é mais ou menos assim:

Se uma versão particular de um arquivo está no diretório Git, ela é considerada commitada. Se ela foi modificada e foi adicionada à área de preparação, ela está preparada. E se ela foi alterada desde o checkout, mas não foi preparada, ela está modificada. No Fundamentos do Git, você aprenderá mais sobre esses estados e como você pode tirar vantagem deles ou pular a parte preparada inteiramente.