Git | |
---|---|
Desenvolvedor | Linus Torvalds, Junio Hamano |
Plataforma | Multiplataforma |
Lançamento | 7 de abril de 2005 (19 anos) |
Versão estável | 2.45.2[1] (31 maio 2024) |
Mercado-alvo | Versionamento de Software |
Escrito em | C, Shell, Perl |
Sistema operacional | POSIX |
Gênero(s) | Sistema de controle de versões |
Licença | GNU GPLv2 |
Estado do desenvolvimento | Corrente |
Tamanho | ~44MB |
Página oficial | git-scm |
Git pronuncia-se [git] (ou /ɡɪt/ em inglês britânico[2][3]) é 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.[4]
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.
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: [5][6][7]
Eu sou um desgraçado egocêntrico, então batizo todos os meus projetos com meu nome. Primeiro Linux, agora Git.Original (em inglês): I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.— Linus Torvalds(em inglês)
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).[8]
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"[6]
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.[9] 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).[10]
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:[11]
De qualquer forma, os SCVs que olhei dificultam as coisas. Uma delas (a maior delas, na verdade) que estive trabalhando é fazer este processo ser realmente eficiente. Se leva meio minuto para aplicar um patch e ainda lembrar o que mudou, etc (e francamente, isso é rápido para a maioria dos SCVs por aí para um projeto do tamanho do Linux), daí uma série de 250 e-mails (que não é estranho acontecer quando eu sincronizo com o Andrew, por exemplo) demora duas horas. Se um dos patches no meio do processo não é aplicado, as coisas ficam realmente muito feias.
Agora, o BK (BitKeeper) não era um inferno também (na verdade, comparado com todo o resto, o BK é um inferno em velocidade, geralmente em uma ou duas ordens de magnitude), e levou cerca de 10-15 segundos por e-mail quando mesclei meus arquivos com o Andrew. MESMO ASSIM, com o BK isso não era um problema tão grande, visto que mesclas de arquivos de BK←>BK eram tão fáceis, eu nunca precisei das lentas mesclas por e-mail com nenhum dos outros desenvolvedores principais. Então um "mesclador" de um SCV baseado em patches precisaria ser realmente mais rápido que o BK. O que realmente é extremamente difícil.
Então eu estou escrevendo alguns scripts para tentar alinhar tudo mais rápido. Indicações iniciais são de que eu poderei fazer isso tão rápido quanto eu aplico patches, mas para ser franco, estou no máximo com metade pronto, e se eu estiver na direção errada, talvez essa não seja a mais pura verdade. De qualquer forma, a razão de que eu consigo criar tudo isso tão rápido é que meus scripts não serão um SCV, serão tipo um "registro de estado do Linus" bem específico. Isso vai fazer minhas mesclas lineares de patches muito mais eficientes no tempo, e nestas condições, possível.
(Se a aplicação de um patch demora três segundos, até mesmo uma série grande de patches não é um problema: se eu for notificado em um minuto ou dois que falhou na metade do caminho, sem problemas, eu posso então simplesmente arrumar manualmente. É por isso que a latência é crítica - se eu tivesse que fazer as coisas efetivamente "desconectado", eu não poderia, por definição, arrumar as coisas quando problemas aparecessem).
Torvalds teve vários critérios para o projeto:
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.[14] O projeto foi anunciado em 6 de Abril,[15] e tornou-se auto-hospedeiro no dia 7 de Abril.[14] A primeira mescla de arquivos (merge) em múltiplos ramos (branches) foi realizado em 18 de Abril.[16] 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.[17] No dia 16 de Junho, a entrega do kernel 2.6.12 foi gerenciada pelo Git.[18]
Mesmo que fortemente influenciado pelo BitKeeper, Torvalds deliberadamente tentou evitar abordagens tradicionais, levando a um design único.[19] 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.[20] Hamano foi responsável pela entrega da versão 1.0 em 21 de dezembro de 2005,[21] e continua como responsável pela manutenção do mesmo.
O desenho do Git foi inspirado no BitKeeper e no Monotone.[22][23] 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.[23] 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.[24]
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:
git gc --prune
pode ser uma operação lenta.[32]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.[33] 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:
O Git implementa várias estratégias de merge (mescla de arquivos); uma não padrão pode ser selecionada durante um merge:[39]
Como o BitKeeper, o Git não usa um servidor centralizado. Entretanto, os primórdios do Git não são inerentemente um sistema de gerenciamento de versão. Torvalds explica:[41]
Você pode ver o git apenas como um sistema de arquivos por vários motivos — ele é um armazenamento endereçável de conteúdo (SCM), e tem o conceito de versionamento, mas eu realmente o modelei vindo de um problema no ponto de vista de um sistema de arquivos (ei, eu faço núcleos de sistemas operacionais), e na verdade eu não tenho absolutamente nenhum interesse em criar um sistema tradicional de SCM.
Apesar de suas intenções, o Git agora possui toda a coleção de funcionalidade de um SCM tradicional.[42]
O Git possuí duas estruturas de dados: um índice mutável que provê informações sobre o diretório de trabalho e a próxima revisão a ser cometida; e um banco de dados de objetos de acréscimo imutável.
O banco de dados de objetos contém quatro tipos de objetos:
O índice serve como um ponto de conexão entre o banco de dados de objetos e a árvore de trabalho.
Cada objeto é identificado por um hash SHA-1 de seu conteúdo. O Git computa o hash e usa esse valor como nome para o objeto. O objeto é colocado em um diretório que corresponde aos primeiros dois caracteres deste hash. O resto do hash é usado como um nome de arquivo para cada objeto.
O Git armazena cada revisão do arquivo com um único objeto blob. Os relacionamentos entre os blobs podem ser encontrados por examinar à árvore de objetos commit. Objetos recém adicionados são armazenados internamente usando compressão do zlib. Isto pode consumir uma grande quantidade de espaço de disco rapidamente. Desta forma, os objetos são combinados em pacotes, que são comprimidos em delta para salvar espaço, gravando blobs como mudanças relativas a outros blobs.
Servidores Git tipicamente escutam na porta TCP/IP 9418.[43]
O Git está primariamente desenvolvido para Linux, mas pode ser usado em outros sistemas operacionais baseados no Unix, incluindo o BSD, o Solaris e o Darwin. O Git é extremamente rápido em arquiteturas POSIX como o Linux.[44]
O Git também roda no Microsoft Windows. Existem duas variantes:
Outras alternativas para rodar o Git inclui:
Refatorar as operações de mais baixo nível em bibliotecas poderia, teoricamente, permitir a reimplementação do componente de níveis mais altos para o Windows sem reescrever o resto.[54]
Os seguintes websites provêm hospedagem gratuita de código fonte para repositório Git:[55]
Um grande número de projetos de software de alto-padrão estão utilizando agora o Git como controle de revisão:[56]
O projeto KDE começou a migrar para o Git, o Amarok completou sua migração[121][122] e logo também a do Phonon.[123] A comunidade do Drupal recentemente anúnciou planos para migrar o desenvolvimento para Git.[124]
When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."
One aspect that really sets Git apart is its speed. …dependence on repository size is very, very weak. For all facts and purposes, Git shows nearly a flat-line behavior when it comes to the dependence of its performance on the number of files and/or revisions in the repository, a feat no other VCS in this review can duplicate (although Mercurial does come quite close).
git-blame
to show code moved between source files
GNOME to migrate to git version control system…
The Perl Foundation has migrated Perl 5 to the Git version control system…