miniaturadaimagem|Imagem ilustrativa Git (ou em inglês britânico) é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo (Exemplo: alguns livros digitais são disponibilizados no GitHub e escrito aos poucos publicamente). O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos.
Cada diretório de trabalho do Git é um repositório com um histórico completo e habilidade total de acompanhamento das revisões, não dependente de acesso a uma rede ou a um servidor central. O Git também facilita a reprodutibilidade científica em uma ampla gama de disciplinas, da ecologia à bioinformática, arqueologia à zoologia.
O Git é um software livre, distribuído sob os termos da versão 2 da GNU General Public License. Sua manutenção é atualmente supervisionada por Junio Hamano.
Nome Quando perguntado sobre o porquê do nome, Linus Torvalds satirizou sobre o termo "Git", uma gíria em inglês britânico para cabeça dura, pessoas que acham que sempre têm razão, argumentativas, podendo ser também pessoa desagradável ou estúpida:
Isto é especialmente irônico, pois o próprio Linus resistiu à ideia de escolher o nome Linux para o núcleo do sistema operacional criado por ele, por ser "too complacent" ("muito arrogante", em tradução livre).Torvalds, Linus and David Diamond, Just for Fun: The Story of an Accidental Revolutionary, 2001, ISBN 0-06-662072-4
Na wiki oficial, há explicações alternativas do próprio Torvald, explicando que Git pode significar qualquer coisa, depende de seu humor. Podendo ser, meramente uma combinação de três letras pronunciáveis e não utilizadas atualmente por nenhum comando comum do UNIX; o retro acrônimo de Global information tracker, em português, Rastreamento global de informações; Ou, quando ele trava, "Goddamn idiotic truckload of sh*t"
História Inicial do Git O desenvolvimento do Git surgiu após vários desenvolvedores do kernel (núcleo) do Linux decidirem desistir de acessar ao sistema do BitKeeper, que é um software proprietário. O acesso gratuito ao BitKeeper foi removido pelo detentor dos direitos autorais, Larry McVoy, depois de acusar Andrew Tridgell de usar de engenharia reversa nos protocolos do BitKeeper, alegando violação da licença do mesmo. Tridgell demonstrou, em uma apresentação na Linux.Conf.Au, realizada em 2005, que o processo de engenharia reversa utilizado não foi mais do que simplesmente direcionar um telnet para a porta apropriada de um servidor BitKeeper e digitar "help" (ajuda).
Torvalds queria um sistema distribuído que ele pudesse utilizar de forma similar ao BitKeeper (BK), mas nenhum dos sistemas livres disponíveis atendia suas necessidades, particularmente com relação à performance. Segue abaixo uma parte retirada de um e-mail, de 7 de Abril de 2005, escrito enquanto desenvolvia seu primeiro protótipo:
Torvalds teve vários critérios para o projeto: Tomar o CVS como um exemplo do que não fazer; na dúvida, tomar exatamente a decisão contrária. Para citar Torvalds, de certa forma mordendo a língua: "Nos primeiros 10 anos de manutenção do kernel, nós literalmente usamos patches de tarballs, o que é muito superior como controle de versão que o CVS, mas eu acabei usando o CVS por 7 anos em uma empresa comercial [Transmeta] e eu odiava de paixão. Quando eu digo que eu odiava de paixão, eu também tenho que dizer que, se houver algum usuário de SVN (Subversion) na platéia, talvez você queira sair. Porque meu ódio pelo CVS significa que eu vejo o Subversion como sendo o projeto iniciado mais sem objetivo de todos os tempos. O slogan do Subversion por um tempo foi "CVS feito [do jeito] certo", ou algo assim, e se você começa com esse slogan, você não vai a lugar nenhum. Não tem como o CVS fazer [do jeito] certo." Suportar um fluxo distribuído, como o BitKeeper "O BitKeeper não foi simplesmente o primeiro sistema de versionamento que eu senti que absolutamente valia a pena, foi também o sistema de controle de versão que me ensinou porque eles têm um objetivo, e como você realmente deve fazer as coisas. Então o Git, de várias formas, mesmo que de uma visão técnica muito diferente do BitKeeper (e isso foi outro objetivo de projeto, porque eu queria deixar claro que não era um plágio do BitKeeper), muitos dos fluxos que usamos no Git vieram diretamente dos fluxos que aprendemos com o BitKeeper." Várias firmes proteções contra corrompimento de arquivos, seja por acidente ou origem maldosa Uma breve descrição dos objetivos de integridade de dados no projeto do Git. Alto desempenho Os primeiros três critérios acima eliminam cada controle de versão preexistente ao Git, exceto pelo Monotone, e o quarto elimina todos. Então, imediatamente depois de liberar a versão 2.6.12-rc2 de desenvolvimento do kernel do Linux, ele começou a desenvolver o seu próprio.
O desenvolvimento do Git começou em 3 de Abril de 2005. O projeto foi anunciado em 6 de Abril, e tornou-se auto-hospedeiro no dia 7 de Abril. A primeira mescla de arquivos (merge) em múltiplos ramos (branches) foi realizado em 18 de Abril. Torvalds alcançou seus objetivos de performance; em 29 de Abril, o recém-nascido Git se tornou referência ao registrar patches para a árvore de desenvolvimento do kernel do Linux na taxa de 6,7 por segundo. No dia 16 de Junho, a entrega do kernel 2.6.12 foi gerenciada pelo Git.
Mesmo que fortemente influenciado pelo BitKeeper, Torvalds deliberadamente tentou evitar abordagens tradicionais, levando a um design único. A discussion of Git vs. BitKeeper Ele desenvolveu o sistema até que fosse possível sua utilização por usuários técnicos, entregando então a manutenção do software para Junio Hamano, um dos principais colaboradores do projeto, em 16 de Julho de 2005. Hamano foi responsável pela entrega da versão 1.0 em 21 de dezembro de 2005, e continua como responsável pela manutenção do mesmo.
Desenho O desenho do Git foi inspirado no BitKeeper e no Monotone. "Some historical background" on git's predecessors Seu desenho original era de um controle de versão de baixo nível, de forma que outros pudessem desenvolver interfaces em cima dele, como por exemplo o Cogito ou o StGIT. No entanto, o núcleo do projeto do Git se tornou, desde então, um sistema de controle de versão completo que pode ser diretamente utilizado.
Características O projeto do Git é uma síntese da experiência de Torvalds com a manutenção do desenvolvimento altamente distribuído do projeto do Linux, junto com seu íntimo conhecimento de performance de sistemas de arquivos (conhecimentos adquiridos no mesmo projeto) e a necessidade urgente de produzir um sistema funcional em um curto espaço de tempo. Essas influências o levaram às seguintes escolhas de implementação:
Suporte consistente para desenvolvimentos não lineares O Git suporta rápidas criações de ramos (branches) e mesclas (merges), e inclui ferramentas específicas para visualização e navegação de históricos de desenvolvimento não lineares. Uma suposição intrínseca no Git é que uma mudança será mesclada mais do que é escrita, enquanto é passada por vários revisores. Desenvolvimento distribuído Assim como o Darcs, o BitKeeper, o Mercurial, o SVK, o Bazaar e o Monotone, o Git dá a cada desenvolvedor uma cópia local completa de todo o histórico de desenvolvimento, e as mudanças são copiadas de um único repositório para outro. Estas mudanças são importadas como ramos (branches) adicionais de desenvolvimento, e podem sofrer uma mescla (merge) da mesma forma que um ramo de desenvolvimento local.
Compatibilidade com protocolos/sistemas existentes Repositórios podem ser publicados por HTTP, FTP, rsync, um protocolo Git sobre uma porta conhecida ou por SSH. O Git também tem uma emulação de servidor CVS, o que habilita a existência de clientes CVS e extensões (plugins) em diversos ADIs a utilizar os repositórios Git. O Subversion e o svk podem utilizar os repositórios diretamente com o git-svn. Manipulação eficiente de projetos extensos Torvalds descreveu o Git como sendo veloz e escalável, e testes de performance realizados pela Mozilla apontaram que o Git é uma ordem de magnitude mais rápido que alguns sistemas de controle de versão. Obter o histórico das revisões salvos em repositórios locais resulta ser duas ordens de magnitude mais rápido que obtê-los de um servidor remoto., benchmarking "git diff" against "bzr diff", and finding the former 100x faster in some cases., observing that "git log" is 100x faster than "svn log" because the latter has to contact a remote server. Um detalhe interessante é que o Git não fica mais lento com o aumento do histórico do projeto.
Autenticação criptográfica do histórico O histórico do Git é salvo de uma maneira que o nome de uma determinada revisão (um "commit", ou entrega, nos termos do Git) depende de todo o histórico de desenvolvimento que leva até este commit. Uma vez publicado, não é possível mudar as versões antigas sem passar despercebido. A estrutura é similar a uma árvore hash (hash tree), mas com dados adicionais nos nós e nas folhas. (o Mercurial e o Monotone também possuem esta propriedade.) Modelo baseado em ferramentas O Git foi modelado como um conjunto de programas escrito em C, e numerosos scripts em shell que encapsulam estes programas., describing Git's script-oriented design Embora muitos destes scripts tenham sido reescritos em C, como parte de um esforço de portar o Git para o Windows, o modelo básico continua, sendo fácil agrupar seus componentes., praising Git's scriptability
Estratégias de mescla (merge) conectáveis Como parte de desenho em ferramentas, o GIT possui um conjunto de algoritmos bem definidos para mesclagem de códigos, realizando uma junção(merge) dos arquivos e avisando o desenvolvedor quando ocorrer conflitos entre o mesmo arquivo, mas de versões distintas O lixo se acumula se não for limpo Abortar operações ou desfazer mudanças irá deixar objetos sem valor pendentes no banco de dados. Existe porém uma pequena fração desejável de objetos no sempre crescente histórico, mas liberar o espaço usando git gc --prune pode ser uma operação lenta.
Empacotamento periódico explícito de objetos O Git armazena cada novo objeto criado como um arquivo separado. Embora cada arquivo seja individualmente comprimido, isso requer um espaço considerável no disco e é ineficiente. Isto é resolvido com o uso de "pacotes" que armazenam um grande número de objetos em um único arquivo (ou pela rede), comprimidos pelo delta entre eles. Pacotes são comprimidos usando a heurística de que arquivos com o mesmo nome são provavelmente similares, mas que não dependam exatamente disso. Mesmo assim, novos objetos criados (novo histórico adicionado) são gravados um a um, e reempacotamentos periódicos são necessários para manter o espaço de forma eficiente. O Git faz reempacotamentos periódicos automaticamente, mas também é possível fazer reempacotamentos manuais com o comando git gc. Outra propriedade do Git é que ele salva o estado (snapshot) dos diretórios de arquivos. Os sistemas mais antigos de controle de versão de código fonte, Sistemas de Controle de Código Fonte (SCCF) e Sistemas de Controle de Revisão (SCR), trabalhavam em cima de arquivos individuais, enfatizando o espaço em disco ganho por intercalação de deltas (SCCF) ou por codificação de deltas (RCS) entre versões (mais similares). Sistemas de controle de versão posteriores mantiveram esta noção de arquivos possuírem uma identidade através de múltiplas revisões de um projeto. Porém, Torvalds rejeitou esse conceito. Consequentemente, o Git não salva relacionamentos entre revisão de arquivos em nenhum nível abaixo da árvore de diretório do código fonte.
Relacionamentos inexplícitos de revisão remete a consequências significativas: