![\"xkcd](\"https://imgs.xkcd.com/comics/git.png\")
Sistemas de controle de versão (VCSs) são ferramentas usadas para rastrear mudanças no código-fonte (ou outras coleções de arquivos e pastas). Como o nome implica, essas ferramentas ajudam a manter um histórico de mudanças; além disso, elas facilitam a colaboração. VCSs rastreiam mudanças em uma pasta e seu conteúdo em uma série de snapshots, onde cada snapshot encapsula o estado completo de arquivos/pastas dentro de um diretório de nível superior. VCSs também mantêm metadados como quem criou cada snapshot, mensagens associadas a cada snapshot, e assim por diante.
\n\nPor que o controle de versão é útil? Mesmo quando você está trabalhando sozinho, ele pode permitir que você veja snapshots antigos de um projeto, mantenha um registro de por que certas mudanças foram feitas, trabalhe em branches paralelos de desenvolvimento, e muito mais. Ao trabalhar com outros, é uma ferramenta inestimável para ver o que outras pessoas mudaram, bem como resolver conflitos no desenvolvimento concorrente.
\n\nVCSs modernos também permitem que você responda facilmente (e frequentemente automaticamente) perguntas como:
\n\nEmbora outros VCSs existam, Git é o padrão de fato para controle de versão. Este quadrinho do XKCD captura a reputação do Git:
\n\n
Como a interface do Git é uma abstração com vazamentos, aprender Git de cima para baixo (começando com sua interface / interface de linha de comando) pode levar a muita confusão. É possível memorizar um punhado de comandos e pensar neles como encantamentos mágicos, e seguir a abordagem no quadrinho acima sempre que algo der errado.
\n\nEmbora o Git admitidamente tenha uma interface feia, seu design e ideias subjacentes são bonitos. Enquanto uma interface feia tem que ser memorizada, um design bonito pode ser compreendido. Por esta razão, damos uma explicação de baixo para cima do Git, começando com seu modelo de dados e depois cobrindo a interface de linha de comando. Uma vez que o modelo de dados é compreendido, os comandos podem ser melhor compreendidos em termos de como eles manipulam o modelo de dados subjacente.
\n\nExistem muitas abordagens ad-hoc que você poderia adotar para controle de versão. O Git tem um modelo bem pensado que habilita todos os recursos agradáveis do controle de versão, como manter histórico, suportar branches e habilitar colaboração.
\n\nO Git modela o histórico de uma coleção de arquivos e pastas dentro de algum diretório de nível superior como uma série de snapshots. Na terminologia do Git, um arquivo é chamado de \"blob\", e é apenas um monte de bytes. Um diretório é chamado de \"tree\", e ele mapeia nomes para blobs ou trees (então diretórios podem conter outros diretórios). Um snapshot é a tree de nível superior que está sendo rastreada. Por exemplo, podemos ter uma tree como segue:
\n\n<root> (tree)\n|\n+- foo (tree)\n| |\n| + bar.txt (blob, contents = \"hello world\")\n|\n+- baz.txt (blob, contents = \"git is wonderful\")\nA tree de nível superior contém dois elementos, uma tree \"foo\" (que ela mesma contém um elemento, um blob \"bar.txt\"), e um blob \"baz.txt\".
\n\nComo um sistema de controle de versão deveria relacionar snapshots? Um modelo simples seria ter um histórico linear. Um histórico seria uma lista de snapshots em ordem temporal. Por muitas razões, o Git não usa um modelo simples como este.
\n\nNo Git, um histórico é um grafo acíclico direcionado (DAG) de snapshots. Isso pode soar como uma palavra matemática sofisticada, mas não se intimide. Tudo isso significa é que cada snapshot no Git se refere a um conjunto de \"pais\", os snapshots que o precederam. É um conjunto de pais em vez de um único pai (como seria o caso em um histórico linear) porque um snapshot pode descender de múltiplos pais, por exemplo, devido à combinação (merge) de dois branches paralelos de desenvolvimento.
\n\nO Git chama esses snapshots de \"commit\"s. Visualizar um histórico de commits pode parecer algo assim:
\n\no <-- o <-- o <-- o\n ^\n \\\n --- o <-- o\nNa arte ASCII acima, os os correspondem a commits individuais (snapshots). As setas apontam para o pai de cada commit (é uma relação \"vem antes\", não \"vem depois\"). Após o terceiro commit, o histórico se ramifica em dois branches separados. Isso pode corresponder a, por exemplo, duas funcionalidades separadas sendo desenvolvidas em paralelo, independentemente uma da outra. No futuro, esses branches podem ser mesclados para criar um novo snapshot que incorpora ambas as funcionalidades, produzindo um novo histórico que se parece com isto, com o commit de merge recém-criado mostrado em negrito:
\n\no <-- o <-- o <-- o <---- o\n ^ /\n \\ v\n --- o <-- o\n\n\n\nCommits no Git são imutáveis. Isso não significa que erros não possam ser corrigidos, no entanto; é apenas que \"edições\" no histórico de commits estão na verdade criando commits inteiramente novos, e referências (veja abaixo) são atualizadas para apontar para os novos.
\n\nPode ser instrutivo ver o modelo de dados do Git escrito em pseudocódigo:
\n\n// um arquivo é um monte de bytes\ntype blob = array<byte>\n\n// um diretório contém arquivos e diretórios nomeados\ntype tree = map<string, tree | blob>\n\n// um commit tem pais, metadados e a tree de nível superior\ntype commit = struct {\n parents: array<commit>\n author: string\n message: string\n snapshot: tree\n}\nÉ um modelo de histórico limpo e simples.
\n\nUm \"objeto\" é um blob, tree ou commit:
\n\ntype object = blob | tree | commit\nNo armazenamento de dados do Git, todos os objetos são endereçados por conteúdo pelo seu hash SHA-1.
\n\nobjects = map<string, object>\n\ndef store(object):\n id = sha1(object)\n objects[id] = object\n\ndef load(id):\n return objects[id]\nBlobs, trees e commits são unificados desta forma: eles são todos objetos. Quando eles referenciam outros objetos, eles não os contêm realmente em sua representação em disco, mas têm uma referência a eles pelo seu hash.
\n\nPor exemplo, a tree para a estrutura de diretório de exemplo acima (visualizada usando git cat-file -p 698281bc680d1995c5f4caaf3359721a5a58d48d), se parece com isto:
100644 blob 4448adbf7ecd394f42ae135bbeed9676e894af85 baz.txt\n040000 tree c68d233a33c5c06e0340e4c224f0afca87c8ce87 foo\nA tree em si contém ponteiros para seu conteúdo, baz.txt (um blob) e foo (uma tree). Se olharmos para o conteúdo endereçado pelo hash correspondente a baz.txt com git cat-file -p 4448adbf7ecd394f42ae135bbeed9676e894af85, obtemos o seguinte:
git is wonderful\nAgora, todos os snapshots podem ser identificados pelos seus hashes SHA-1. Isso é inconveniente, porque humanos não são bons em lembrar strings de 40 caracteres hexadecimais.
\n\nA solução do Git para este problema são nomes legíveis por humanos para hashes SHA-1, chamados \"referências\". Referências são ponteiros para commits. Diferente de objetos, que são imutáveis, referências são mutáveis (podem ser atualizadas para apontar para um novo commit). Por exemplo, a referência master geralmente aponta para o último commit no branch principal de desenvolvimento.
references = map<string, string>\n\ndef update_reference(name, id):\n references[name] = id\n\ndef read_reference(name):\n return references[name]\n\ndef load_reference(name_or_id):\n if name_or_id in references:\n return load(references[name_or_id])\n else:\n return load(name_or_id)\nCom isso, o Git pode usar nomes legíveis por humanos como \"master\" para se referir a um snapshot específico no histórico, em vez de uma longa string hexadecimal.
\n\nUm detalhe é que frequentemente queremos uma noção de \"onde estamos atualmente\" no histórico, para que quando tiramos um novo snapshot, saibamos o que é relativo a (como definimos o campo parents do commit). No Git, esse \"onde estamos atualmente\" é uma referência especial chamada \"HEAD\".
Finalmente, podemos definir o que (aproximadamente) é um repositório Git: são os dados objects e references.
No disco, tudo que o Git armazena são objetos e referências: isso é tudo que há no modelo de dados do Git. Todos os comandos git mapeiam para alguma manipulação do DAG de commits adicionando objetos e adicionando/atualizando referências.
Sempre que você estiver digitando qualquer comando, pense sobre qual manipulação o comando está fazendo na estrutura de dados de grafo subjacente. Inversamente, se você está tentando fazer um tipo específico de mudança no DAG de commits, por exemplo, \"descartar mudanças não commitadas e fazer a ref 'master' apontar para o commit 5d83f9e\", provavelmente há um comando para fazer isso (por exemplo, neste caso, git checkout master; git reset --hard 5d83f9e).
Este é outro conceito que é ortogonal ao modelo de dados, mas é uma parte da interface para criar commits.
\n\nUma maneira que você poderia imaginar implementar snapshots como descrito acima seria ter um comando \"criar snapshot\" que cria um novo snapshot baseado no estado atual do diretório de trabalho. Algumas ferramentas de controle de versão funcionam assim, mas não o Git. Queremos snapshots limpos, e pode nem sempre ser ideal fazer um snapshot do estado atual. Por exemplo, imagine um cenário onde você implementou duas funcionalidades separadas, e você quer criar dois commits separados, onde o primeiro introduz a primeira funcionalidade, e o próximo introduz a segunda funcionalidade. Ou imagine um cenário onde você tem declarações de print de debug adicionadas por todo o seu código, junto com uma correção de bug; você quer commitar a correção de bug enquanto descarta todas as declarações de print.
\n\nO Git acomoda tais cenários permitindo que você especifique quais modificações devem ser incluídas no próximo snapshot através de um mecanismo chamado \"área de staging\".
\n\nPara evitar duplicar informações, não vamos explicar os comandos abaixo em detalhes. Veja o altamente recomendado Pro Git para mais informações.
\n\nO comando git init inicializa um novo repositório Git, com metadados do repositório sendo armazenados no diretório .git:
$ mkdir myproject\n$ cd myproject\n$ git init\nInitialized empty Git repository in .git\n$ git status\nOn branch master\nNo commits yet\nnothing to commit (create/copy files and use \"git add\" to track)\nComo interpretamos esta saída? \"No commits yet\" basicamente significa que nosso histórico de versão está vazio. Vamos consertar isso.
\n\n$ echo \"hello, git\" > hello.txt\n$ git add hello.txt\n$ git status\nOn branch master\nNo commits yet\nChanges to be committed:\n (use \"git rm --cached <file>...\" to unstage)\n new file: hello.txt\n$ git commit -m 'Initial commit'\n[master (root-commit) 4515d17] Initial commit\n 1 file changed, 1 insertion(+)\n create mode 100644 hello.txt\nCom isso, fizemos git add de um arquivo para a área de staging, e então fizemos git commit dessa mudança, adicionando uma mensagem de commit simples \"Initial commit\". Se não especificássemos uma opção -m, o Git abriria nosso editor de texto para nos permitir digitar uma mensagem de commit.
Agora que temos um histórico de versão não vazio, podemos visualizar o histórico. Visualizar o histórico como um DAG pode ser especialmente útil para entender o status atual do repositório e conectá-lo com seu entendimento do modelo de dados do Git.
\n\nO comando git log visualiza o histórico. Por padrão, ele mostra uma versão achatada, que esconde a estrutura de grafo. Se você usar um comando como git log --all --graph --decorate, ele mostrará o histórico de versão completo do repositório, visualizado em forma de grafo.
$ git log --all --graph --decorate\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa (HEAD -> master)\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nIsso não parece muito com um grafo, porque contém apenas um único nó. Vamos fazer mais algumas mudanças, criar um novo commit e visualizar o histórico mais uma vez.
\n\n$ echo \"another line\" >> hello.txt\n$ git status\nOn branch master\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git checkout -- <file>...\" to discard changes in working directory)\n modified: hello.txt\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add hello.txt\n$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD <file>...\" to unstage)\n modified: hello.txt\n$ git commit -m 'Add a line'\n[master 35f60a8] Add a line\n 1 file changed, 1 insertion(+)\nAgora, se visualizarmos o histórico novamente, veremos um pouco da estrutura de grafo:
\n\n* commit 35f60a825be0106036dd2fbc7657598eb7b04c67 (HEAD -> master)\n| Author: Subramanya N <subramanyanagabhushan@gmail.com>\n| Date: Tue Dec 21 22:26:20 2020 -0500\n| Add a line\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nAlém disso, note que ele mostra o HEAD atual, junto com o branch atual (master).
\n\nPodemos olhar versões antigas usando o comando git checkout.
$ git checkout 4515d17 # hash do commit anterior; o seu será diferente\nNote: checking out '4515d17'.\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by performing another checkout.\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -b with the checkout command again. Example:\n git checkout -b <new-branch-name>\nHEAD is now at 4515d17 Initial commit\n$ cat hello.txt\nhello, git\n$ git checkout master\nPrevious HEAD position was 4515d17 Initial commit\nSwitched to branch 'master'\n$ cat hello.txt\nhello, git\nanother line\nO Git pode mostrar como os arquivos evoluíram (diferenças, ou diffs) usando o comando git diff:
$ git diff 4515d17 hello.txt\ndiff --git c/hello.txt w/hello.txt\nindex 94bab17..f0013b2 100644\n--- c/hello.txt\n+++ w/hello.txt\n@@ -1 +1,2 @@\n hello, git\n +another line\ngit help <command>: obter ajuda para um comando gitgit init: cria um novo repositório git, com dados armazenados no diretório .gitgit status: diz o que está acontecendogit add <filename>: adiciona arquivos à área de staginggit commit: cria um novo commit\ngit log: mostra um log achatado do históricogit log --all --graph --decorate: visualiza o histórico como um DAGgit diff <filename>: mostra mudanças que você fez relativas à área de staginggit diff <revision> <filename>: mostra diferenças em um arquivo entre snapshotsgit checkout <revision>: atualiza HEAD e branch atualBranching permite que você \"bifurque\" o histórico de versão. Pode ser útil para trabalhar em funcionalidades independentes ou correções de bugs em paralelo. O comando git branch pode ser usado para criar novos branches; git checkout -b <branch name> cria um branch e faz checkout dele.
Merging é o oposto de branching: ele permite que você combine históricos de versão bifurcados, por exemplo, mesclando um branch de funcionalidade de volta ao master. O comando git merge é usado para mesclar.
git branch: mostra branchesgit branch <name>: cria um branchgit checkout -b <name>: cria um branch e muda para ele\ngit branch <name>; git checkout <name>git merge <revision>: mescla no branch atualgit mergetool: usa uma ferramenta sofisticada para ajudar a resolver conflitos de mergegit rebase: rebaseia conjunto de patches em uma nova basegit remote: lista remotosgit remote add <name> <url>: adiciona um remotogit push <remote> <local branch>:<remote branch>: envia objetos para o remoto e atualiza referência remotagit branch --set-upstream-to=<remote>/<remote branch>: configura correspondência entre branch local e remotogit fetch: recupera objetos/referências de um remotogit pull: mesmo que git fetch; git mergegit clone: baixa repositório de um remotogit commit --amend: edita o conteúdo/mensagem de um commitgit reset HEAD <file>: remove um arquivo da staginggit checkout -- <file>: descarta mudançasgit config: Git é altamente customizávelgit clone --depth=1: clone raso, sem todo o histórico de versãogit add -p: staging interativogit rebase -i: rebasing interativogit blame: mostra quem editou por último qual linhagit stash: remove temporariamente modificações do diretório de trabalhogit bisect: busca binária no histórico (por exemplo, para regressões).gitignore: especifica arquivos intencionalmente não rastreados para ignorar