O que é Git?

docs.scrimba.com

Você quase certamente já fez controle de versão manualmente. Uma pasta com relatorio.docx, relatorio_final.docx, relatorio_final_v2.docx e relatorio_final_DE_VERDADE.docx é controle de versão, do pior tipo possível. Você não consegue dizer o que mudou entre dois desses arquivos, não consegue mesclar edições que duas pessoas fizeram ao mesmo tempo, e definitivamente não consegue recuperar o parágrafo bom que você deletou três cópias atrás.

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

O que Git faz por você

No seu cerne, 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 cada arquivo, mais 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 aonde está. Aqui está uma linha do tempo real, impressa por git log, o comando que lista os commits de um projeto (a flag --oneline encurta cada um para uma única linha):

$ git log --oneline
a1b2c3d Add password strength meter
9f8e7d6 Fix signup form validation
5c4b3a2 Set up project structure

Esses são três pontos salvos no histórico de um projeto, o mais novo no topo, cada um com um ID curto e a mensagem que seu autor escreveu. (Em cada exemplo como este, a linha começando com $ é um comando digitado em um terminal, sem o $ em si, e as linhas abaixo dele são a resposta do Git.) Você aprenderá cada comando que produz e lê esse histórico nos próximos capítulos. Por enquanto, a ideia importante é que Git está registrando seu trabalho como uma série de snapshots aos quais você sempre pode voltar.

Uma vez que seu projeto tenha um histórico como este, muito se torna possível. Você pode ver o que mudou e quem mudou. Você pode tentar uma ideia arriscada à parte e descartá-la completamente se não funcionar. Você pode entregar o projeto inteiro, com seu histórico completo, para outra pessoa. E quando duas pessoas editam o mesmo código, Git pode combinar seu trabalho e marcar os locais onde discordam para que um humano possa resolvê-los. Essas quatro capacidades, histórico, experimentos seguros, compartilhamento e combinação de trabalho, são toda a razão pela qual Git roda em quase todos os codebases profissionais.

Na prática, um time depende dessa linha do tempo constantemente. Cada mudança de qualquer tamanho começa em sua própria branch, uma linha separada de histórico 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 para a branch principal. Revisar, fazer branches e mesclar são o ritmo diário de trabalhar em Git, e todos descansam na linha do tempo de snapshots acima. O resto deste manual passa por cada peça desse ritmo na ordem em que você encontra.

Um detalhe importa para tudo depois: cada commit armazena o estado completo dos seus arquivos rastreados, um snapshot completo daquele momento. As pessoas frequentemente imaginam que Git salva apenas as diferenças entre versões, mas por baixo cada commit contém o projeto inteiro. Git mantém isso barato armazenando cada conteúdo de arquivo único uma vez, de modo que um commit que reutiliza um arquivo inalterado apenas aponta para a cópia já salva, e um snapshot de mil arquivos onde um mudou não duplica os outros 999. Cada commit também registra o ID do commit que veio antes dele, seu parent, que é como Git vincula snapshots em um histórico que pode caminhar para trás. Esse link parent é a base de quase tudo mais: branches, merges e navegação de histórico são todos construídos sobre seguir esses ponteiros. Você verá o modelo de objeto completo nos capítulos de Histórico e Branches.

JunoO que Git faz por você 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 sobre ele, experimentar com segurança, compartilhá-lo e combinar trabalho com outras pessoas. A pilha de cópias final_v2_DE_VERDADE é o problema que Git foi construído para acabar, e prometo que se sente ótimo na primeira vez que você deleta uma.

JunoO que Git faz por você Um commit é um snapshot mais uma mensagem, e o histórico é uma linha do tempo deles. Dia a dia você faz branches dessa linha do tempo para fazer uma mudança, obtém revisão e mescla de volta. Mantenha o modelo mental de uma linha do tempo crescente de snapshots na sua cabeça; cada comando que você aprende é ou adicionando a ela ou lendo dela.

JunoO que Git faz por você Cada commit armazena o estado do projeto inteiro e aponta para seu parent, que é como Git caminha pelo histórico. Conteúdos de arquivo idênticos são armazenados uma vez e compartilhados entre commits, de modo que snapshots permanecem baratos. Mantenha a ideia do parent-pointer, porque branches e merges são a mesma ideia usando chapéus diferentes.

Git e GitHub são coisas diferentes

Isso confunde quase todo mundo no início, então aqui está em termos simples. Git é a ferramenta de controle de versão. Roda no seu próprio computador, registra seus commits, e não precisa de conexão com a internet ou de uma conta para funcionar. GitHub é um site que armazena repositórios Git online e adiciona coisas ao seu redor: um lugar para compartilhar seu código, revisar as mudanças uns dos outros, reportar problemas e colaborar.

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

A razão pela qual os dois se confundem é que a maioria das pessoas conhece Git e GitHub no mesmo momento, clonando um projeto do GitHub no seu primeiro dia. Muitas pessoas acabam pensando que git push significa "enviar para GitHub", quando na verdade significa "enviar para qualquer remote que você configurou", e esse remote acontece de ser GitHub na maioria das vezes. Manter os dois separados na sua cabeça compensa da primeira vez que você usa Git com um host diferente, ou sem nenhum host.

JunoGit e GitHub são coisas diferentes Git é a ferramenta no seu computador que registra seus commits. GitHub é um site que armazena projetos Git online para que as pessoas possam compartilhá-los e revisá-los. Você pode usar Git sem uma conta GitHub. Se você lembrar uma coisa desta página, que seja esta, porque misturá-los causa tanta confusão inicial.

JunoGit e GitHub são coisas diferentes Git é o motor de controle de versão na sua máquina; GitHub é um lugar popular para hospedar o que ele produz, ao lado de GitLab e Bitbucket. git push envia para qualquer remote que você configurou, que geralmente é GitHub por hábito. Mantenha a separação e você não será confundido quando um projeto vive em outro lugar.

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

De onde Git veio

O histórico do Git explica muito sobre por que ele funciona da forma que funciona. Foi escrito em 2005 por Linus Torvalds, a mesma pessoa que iniciou 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 permitia que projetos open-source usassem gratuitamente.

Em 2005 esse acordo gratuito desabou, e a comunidade do kernel de repente não tinha ferramenta para gerenciar seu enorme e rápido codebase. Nada mais disponível na época conseguia acompanhar. Então Torvalds se afastou do trabalho do kernel por algumas semanas e escreveu sua própria ferramenta de controle de versão, com alguns objetivos firmes moldados por exatamente esse problema.

Ele queria que fosse distribuída, de modo que cada contribuidor tivesse o histórico completo do projeto em sua própria máquina e pudesse trabalhar sem verificar com um servidor central. Ele queria que fosse rápida, rápida o suficiente para lidar com um projeto do tamanho do kernel sem fazer as pessoas esperarem. E queria garantir integridade, de modo que ninguém pudesse silenciosamente alterar o histórico e nenhum erro de disco pudesse corromper um projeto sem ser notado.

Esses objetivos são o motivo pelo qual Git se comporta como faz hoje. Quando você clone um projeto, você obtém seu histórico inteiro para trabalhar, que é o objetivo distribuído em ação: você pode fazer commit, criar branches e navegar o histórico em um avião sem wifi. E cada commit é marcado com uma impressão digital calculada a partir de seu conteúdo exato, então se um único byte jamais mudar a impressão digital para de combinar e Git percebe. As decisões de design que Torvalds fez apressadamente em 2005 são as que você confia em cada vez que usa Git agora.

A garantia de integridade dirige o design inteiro. Cada commit é identificado por um hash, uma impressão digital de comprimento fixo computada a partir do conteúdo completo do commit, incluindo o ID de seu parent. Porque o ID do parent se alimenta no hash do filho, os hashes formam uma cadeia: altere qualquer coisa em um commit antigo e seu hash muda, que muda o hash de cada commit depois dele. É isso que torna o histórico do Git à prova de adulteração. Também significa que o ID de um commit é uma impressão digital de seu conteúdo exato, que é por que você vê essas strings de hex como a1b2c3d em vez de um número de commit arrumado 42.

JunoDe onde Git veio Linus Torvalds escreveu Git em 2005 para o kernel do Linux, depois que a ferramenta que o projeto havia usado deixou de ser gratuita. Ele a construiu para ser distribuída, rápida e segura contra corrupção. É por isso que clone lhe dá o histórico completo para trabalhar offline, e por que cada commit recebe uma impressão digital. Contexto útil para uma ferramenta que você usará por anos.

JunoDe onde Git veio Git saiu do kernel do Linux em 2005, construído para milhares de contribuidores sem servidor central, que é por que seu modelo inteiro é distribuído. Cada clone carrega o histórico completo, de modo que você faz branches e commits localmente e sincroniza quando escolhe. Quando um padrão de Git parece estranho, "foi projetado para o kernel" geralmente o explica.

JunoDe onde Git veio Git saiu de um sprint de duas semanas de Torvalds em 2005 quando o kernel perdeu acesso ao BitKeeper, com três objetivos: distribuído, rápido, com verificação de integridade. O hash de cada commit é computado a partir de seu conteúdo mais o hash de seu parent, de modo que os IDs formam uma cadeia à prova de adulteração. Quando você se pergunta por que Git fez alguma escolha, "foi construído para o kernel do Linux" geralmente é a resposta.

Para onde este manual vai a seguir

Com o modelo mental no lugar, o resto da trilha é sobre fazer o trabalho. Seu primeiro repositório começa do zero: abrindo um terminal, instalando Git se sua máquina não tiver, e transformando uma pasta em um repositório no qual você pode fazer commit. A partir daí você aprenderá o loop cotidiano de salvar mudanças, depois branches, merging e o fluxo de colaboração no GitHub. Se um termo jamais o confundir, o Glossário tem uma definição curta para cada palavra de vocabulário do Git nesses docs.