O que é Git?

docs.scrimba.com

Você quase certamente já fez controle de versão na mão. Uma pasta com relatorio.docx, relatorio_final.docx, relatorio_final_v2.docx e relatorio_final_DEFINITIVO.docx é controle de versão, do peor tipo possível. Você não consegue saber o que mudou entre dois desses arquivos, não consegue combinar as edições que duas pessoas fizeram ao mesmo tempo, e definitivamente não consegue recuperar aquele parágrafo bom que você apagou três cópias atrás.

O Git resolve esse problema de verdade. É uma ferramenta que registra snapshots do seu projeto ao longo do tempo, de modo que todo o histórico fica em um único lugar, em vez de uma pilha de cópias. A ferramenta em si é um pequeno programa instalado no seu próprio computador: você digita comandos que começam com git em um terminal, e ele responde em texto.

O que o Git faz por você

No fundo, o Git mantém uma linha do tempo do seu projeto. Cada vez que você chega a um ponto que vale a pena salvar, você registra um commit: um snapshot de todos os arquivos, junto com uma mensagem curta descrevendo o que mudou e por quê. Depois, você pode olhar para trás nessa linha do tempo e ver exatamente como o projeto chegou até onde está. Aqui está uma linha do tempo real, impressa pelo git log, o comando que lista os commits de um projeto (a flag --oneline resume cada um a uma única linha):

$ git log --oneline
a1b2c3d Adiciona medidor de força de senha
9f8e7d6 Corrige validação do formulário de cadastro
5c4b3a2 Configura estrutura do projeto

Isso são três pontos salvos no histórico de um projeto, o mais recente no topo, cada um com um ID curto e a mensagem escrita por quem o criou. (Em todo exemplo como esse, a linha que começa com $ é um comando digitado em um terminal, sem o próprio $, e as linhas abaixo dela são a resposta do Git.) Você vai aprender todos os comandos que produzem e leem esse histórico nos próximos capítulos. Por agora, a ideia para guardar é que o Git está registrando seu trabalho como uma série de snapshots para os quais você sempre pode voltar.

Assim que seu projeto tem um histórico como esse, muita coisa se torna possível. Você pode ver o que mudou e quem mudou. Você pode testar uma ideia arriscada em paralelo e descartá-la de forma limpa se não der certo. Você pode entregar o projeto inteiro, com todo o seu histórico, para outra pessoa. E quando duas pessoas editam o mesmo código, o Git consegue combinar o trabalho de ambas e sinalizar os pontos em que elas discordam, para que uma pessoa resolva isso. Essas quatro capacidades, histórico, experimentos seguros, compartilhamento e combinação de trabalho, são o motivo pelo qual o Git roda por baixo de quase todo código profissional.

Na prática, um time se apoia nessa linha do tempo o tempo todo. Toda mudança, de qualquer tamanho, começa em sua própria branch, uma linha de histórico separada onde você pode trabalhar sem perturbar o código principal. Quando a mudança está pronta, alguém a revisa, e então ela é mesclada de volta na branch principal. Revisar, criar branches e mesclar são o ritmo diário de trabalhar com Git, e todos eles se apoiam na linha do tempo de snapshots que vimos acima. O restante deste manual percorre cada parte desse ritmo na ordem em que você vai encontrá-la.

Um detalhe importa para tudo o que vem depois: cada commit armazena o estado completo dos seus arquivos rastreados, um snapshot inteiro daquele momento. As pessoas costumam imaginar que o Git salva apenas as diferenças entre versões, mas, na verdade, cada commit guarda o projeto inteiro. O Git mantém isso barato armazenando o conteúdo único de cada arquivo apenas uma vez, então um commit que reaproveita um arquivo não alterado apenas aponta para a cópia já salva, e um snapshot de mil arquivos em que apenas um mudou não duplica os outros 999. Cada commit também registra o ID do commit que veio antes dele, seu parent (pai), e é assim que o Git encadeia os snapshots em um histórico que pode percorrer para trás. Esse link com o parent é a espinha dorsal de quase tudo o mais: branches, merges e a navegação pelo histórico são todos construídos seguindo esses apontadores. Você vai ver o modelo completo de objetos nos capítulos de Histórico e Branches.

JunoO que o Git faz por você O Git registra seu projeto como uma série de snapshots chamados commits, cada um com uma mensagem dizendo o que mudou. Uma vez que esse histórico existe, você pode olhar para trás nele, experimentar com segurança, compartilhá-lo e combinar trabalho com outras pessoas. A pilha de cópias final_v2_DEFINITIVO é o problema que o Git foi criado para acabar, e eu prometo que é uma sensação ótima na primeira vez que você apaga uma dessas.

JunoO que o Git faz por você Um commit é um snapshot mais uma mensagem, e o histórico é uma linha do tempo deles. No dia a dia, você cria uma branch a partir dessa linha do tempo para fazer uma mudança, pede para revisarem e depois mescla de volta. Mantenha na cabeça o modelo mental de uma linha do tempo de snapshots que cresce; todo comando que você aprender ou adiciona a ela, ou lê a partir dela.

JunoO que o Git faz por você Cada commit armazena o estado inteiro do projeto e aponta para seu parent, e é assim que o Git percorre o histórico. Conteúdos de arquivo idênticos são armazenados uma única vez e compartilhados entre commits, então os snapshots continuam baratos. Guarde a ideia do apontador para o parent, porque branches e merges são a mesma ideia com roupagens diferentes.

Git e GitHub são coisas diferentes

Esse é o ponto que confunde quase todo mundo no início, então vamos direto ao ponto. O Git é a ferramenta de controle de versão. Ele roda no seu próprio computador, registra seus commits e não precisa de conexão com a internet nem de conta para funcionar. O GitHub é um site que armazena repositórios Git online e adiciona recursos ao redor deles: um lugar para compartilhar seu código, revisar as mudanças umas das outras, reportar problemas e colaborar.

O jeito mais claro de sentir a diferença: você pode usar o Git todos os dias, fazendo commits e criando branches no seu notebook, sem nunca criar uma conta no GitHub. O GitHub só entra em cena quando você quer colocar seu repositório em algum lugar compartilhado, para que outras pessoas, ou outras máquinas, possam acessá-lo. O Git é o motor; o GitHub é um dos lugares onde você pode hospedar o que ele produz. Existem outros, como o GitLab e o Bitbucket, e todos eles hospedam os mesmos repositórios Git por baixo dos panos.

O motivo pelo qual os dois se misturam na cabeça das pessoas é que a maioria conhece o Git e o GitHub ao mesmo tempo, clonando um projeto do GitHub no primeiro dia. Muita gente acaba pensando que git push significa "enviar para o GitHub", quando na verdade significa "enviar para o remote que você configurou", e esse remote costuma ser o GitHub na maior parte das vezes. Manter os dois separados na sua cabeça vale a pena na primeira vez que você usar o Git com um host diferente, ou sem host nenhum.

JunoGit e GitHub são coisas diferentes O Git é a ferramenta no seu computador que registra seus commits. O GitHub é um site que armazena projetos Git online para que as pessoas possam compartilhá-los e revisá-los. Você pode usar o Git sem ter conta nenhuma no GitHub. Se você guardar só uma coisa desta página, guarde essa, porque confundir os dois causa muita confusão no começo.

JunoGit e GitHub são coisas diferentes O Git é o motor de controle de versão na sua máquina; o GitHub é um dos lugares populares para hospedar o que ele produz, junto com o GitLab e o Bitbucket. O git push envia para o remote que você configurou, que geralmente é o GitHub por hábito. Guarde essa separação e você não vai se surpreender quando um projeto estiver hospedado em outro lugar.

JunoGit e GitHub são coisas diferentes O Git entende de commits, branches e refs; o GitHub adiciona pull requests, issues e o botão de merge por cima de uma cópia hospedada. Nada do que o GitHub adiciona é um comando do Git, e é por isso que você abre um pull request em um site, nunca com o git. Mantenha os dois separados na sua cabeça e a maior parte do que parece mágica do GitHub volta a ser refs simples.

De onde o Git veio

A história do Git explica muita coisa sobre por que ele funciona da forma como funciona. Ele foi escrito em 2005 por Linus Torvalds, a mesma pessoa que criou o Linux. O kernel do Linux é construído por milhares de voluntários espalhados pelo mundo, e por alguns anos eles coordenaram todo esse trabalho usando uma ferramenta comercial chamada BitKeeper, que a empresa por trás dela deixava projetos de código aberto usarem de graça.

Em 2005, esse arranjo gratuito acabou, e a comunidade do kernel de repente ficou sem uma ferramenta para gerenciar sua base de código enorme e em constante movimento. Nada mais disponível na época conseguia acompanhar o ritmo. Então Torvalds se afastou do trabalho no kernel por algumas semanas e escreveu sua própria ferramenta de controle de versão, com algumas metas firmes moldadas exatamente por esse problema.

Ele queria que ela fosse distribuída, de modo que cada colaborador tivesse o histórico completo do projeto na própria máquina e pudesse trabalhar sem precisar se conectar a um servidor central. Ele queria que ela fosse rápida, rápida o suficiente para lidar com um projeto do tamanho do kernel sem fazer as pessoas esperarem. E ele queria garantir a integridade, de modo que ninguém pudesse alterar o histórico silenciosamente e nenhum erro de disco pudesse corromper um projeto sem que isso fosse percebido.

Essas metas explicam por que o Git se comporta como se comporta hoje. Quando você faz clone de um projeto, você recebe todo o seu histórico para trabalhar, o que é a meta de ser distribuído em ação: você pode fazer commits, criar branches e navegar pelo histórico em um avião sem wifi. E cada commit recebe uma impressão digital calculada a partir do seu conteúdo exato, então, se um único byte mudar, a impressão digital deixa de coincidir e o Git percebe. As decisões de design que Torvalds tomou às pressas em 2005 são as mesmas em que você se apoia toda vez que usa o Git hoje.

A garantia de integridade é o que orienta todo o design. Cada commit é identificado por um hash, uma impressão digital de tamanho fixo calculada a partir de todo o conteúdo do commit, incluindo o ID do seu parent. Como o ID do parent alimenta o hash do filho, os hashes formam uma corrente: mude qualquer coisa em um commit antigo e o hash dele muda, o que muda o hash de todo commit que vem depois. É isso que torna o histórico do Git à prova de adulteração. Isso também significa que o ID de um commit é uma impressão digital do seu conteúdo exato, e é por isso que você vê aquelas strings de hexadecimal como a1b2c3d, em vez de um número de commit organizadinho, como 42.

JunoDe onde o Git veio Linus Torvalds escreveu o Git em 2005 para o kernel do Linux, depois que a ferramenta que o projeto vinha usando deixou de ser gratuita. Ele o construiu para ser distribuído, rápido e seguro contra corrupção. É por isso que o clone te dá o histórico completo para trabalhar offline, e por que cada commit recebe uma impressão digital. Um contexto útil para uma ferramenta que você vai usar por anos.

JunoDe onde o Git veio O Git surgiu do kernel do Linux em 2005, construído para milhares de colaboradores sem um servidor central, e é por isso que todo o seu modelo é distribuído. Todo clone carrega o histórico completo, então você cria branches e faz commits localmente e sincroniza quando quiser. Quando algum comportamento padrão do Git parecer estranho, "foi feito para o kernel" geralmente explica o motivo.

JunoDe onde o Git veio O Git surgiu de duas semanas de trabalho intenso de Torvalds em 2005, quando o kernel perdeu o acesso ao BitKeeper, com três metas: distribuído, rápido, com integridade verificada. O hash de cada commit é calculado a partir do seu conteúdo mais o hash do seu parent, então os IDs formam uma corrente à prova de adulteração. Quando você se perguntar por que o Git fez alguma escolha de design, "foi construído para o kernel do Linux" geralmente é a resposta.

Para onde este manual vai a seguir

Com o modelo mental estabelecido, o restante da trilha é sobre pôr a mão na massa. Seu primeiro repositório começa do zero: abrindo um terminal, instalando o Git se a sua máquina ainda não tiver, e transformando uma pasta em um repositório no qual você pode fazer commits. A partir daí, você vai aprender o ciclo do dia a dia de salvar mudanças, depois branches, merges e o fluxo de colaboração no GitHub. Se algum termo te deixar perdido, o Glossário tem uma definição curta para cada palavra do vocabulário do Git usada nestes documentos.