Git - Git

Git
Git-logo-2012.svg
Git session.svg
Uma sessão de linha de comando mostrando a criação de repositório, adição de um arquivo e sincronização remota
Autor (es) original (is) Linus Torvalds
Desenvolvedor (s) Junio ​​Hamano e outros
lançamento inicial 7 de abril de 2005 ; 16 anos atrás ( 07-04-2005 )
Versão estável
2.33.1  Edite isso no Wikidata / 12 de outubro de 2021 ; 4 dias atrás ( 12 de outubro de 2021 )
Repositório
Escrito em C , Shell , Perl , Tcl
Sistema operacional POSIX ( Linux , macOS , Solaris , AIX ), Windows
Disponível em inglês
Modelo Controle de versão
Licença GPL-2.0 somente
Local na rede Internet git-scm .com Edite isso no Wikidata

Git ( / ɡ ɪ t / ) é um software para rastrear alterações em qualquer conjunto de arquivos , geralmente usado para coordenar o trabalho entre programadores que desenvolvem código-fonte de forma colaborativa durante o desenvolvimento de software . Seus objetivos incluem velocidade, integridade de dados e suporte para fluxos de trabalho não lineares distribuídos (milhares de ramificações paralelas em execução em sistemas diferentes).

Git foi criado por Linus Torvalds em 2005 para o desenvolvimento do kernel Linux , com outros desenvolvedores do kernel contribuindo para seu desenvolvimento inicial. Desde 2005, Junio ​​Hamano tem sido o principal mantenedor. Como acontece com a maioria dos outros sistemas de controle de versão distribuídos , e ao contrário da maioria dos sistemas cliente-servidor , cada diretório Git em cada computador é um repositório completo com histórico completo e recursos completos de rastreamento de versão, independente do acesso à rede ou de um servidor central. Git é um software gratuito e de código aberto distribuído sob a licença GPL-2.0 apenas .

História

O desenvolvimento do Git começou em abril de 2005, depois que muitos desenvolvedores do kernel do Linux desistiram de acessar o BitKeeper , um sistema de gerenciamento de controle de origem (SCM) que eles usavam para manter o projeto desde 2002. O detentor dos direitos autorais do BitKeeper, Larry McVoy , retirou o uso gratuito do produto após alegar que Andrew Tridgell havia criado o SourcePuller por meio da engenharia reversa dos protocolos do BitKeeper. O mesmo incidente também estimulou a criação de outro sistema de controle de versão, o Mercurial .

Linus Torvalds queria um sistema distribuído que pudesse usar como o BitKeeper, mas nenhum dos sistemas gratuitos disponíveis atendia às suas necessidades. Torvalds citou um exemplo de um sistema de gerenciamento de controle de origem que precisa de 30 segundos para aplicar um patch e atualizar todos os metadados associados, e observou que isso não seria dimensionado para as necessidades de desenvolvimento do kernel Linux, onde a sincronização com outros mantenedores poderia exigir 250 dessas ações em uma vez. Para seu critério de design, ele especificou que o patch não deve demorar mais do que três segundos e acrescentou mais três objetivos:

  • Considere o Concurrent Versions System (CVS) como um exemplo do que não deve ser feito; em caso de dúvida, tome a decisão exatamente oposta.
  • Suporte a um fluxo de trabalho distribuído semelhante ao BitKeeper .
  • Incluem proteções muito fortes contra corrupção, seja acidental ou mal-intencionada.

Esses critérios eliminaram todos os sistemas de controle de versão em uso na época, então, imediatamente após o lançamento de desenvolvimento do kernel 2.6.12-rc2 Linux, Torvalds decidiu escrever o seu próprio.

O desenvolvimento do Git começou em 3 de abril de 2005. Torvalds anunciou o projeto em 6 de abril e passou a hospedar-se sozinho no dia seguinte. A primeira fusão de várias filiais ocorreu em 18 de abril. Torvalds atingiu seus objetivos de desempenho; em 29 de abril, o Git nascente foi testado gravando patches para a árvore do kernel do Linux a uma taxa de 6,7 patches por segundo. Em 16 de junho, Git gerenciou o lançamento do kernel 2.6.12.

Torvalds transferiu a manutenção em 26 de julho de 2005 para Junio ​​Hamano, um dos principais contribuintes do projeto. Hamano foi responsável pelo lançamento 1.0 em 21 de dezembro de 2005 e continua sendo o principal mantenedor do projeto.

Nomeação

Torvalds brincou sarcasticamente sobre o nome git (que significa "pessoa desagradável" na gíria do inglês britânico ): "Sou um bastardo egoísta e nomeio todos os meus projetos com meu nome. Primeiro ' Linux ', agora 'git'." A página do manual descreve o Git como "o rastreador de conteúdo estúpido". O arquivo leia-me do código-fonte elabora mais:

"git" pode significar qualquer coisa, dependendo do seu humor.

  • Combinação aleatória de três letras que pode ser pronunciada e, na verdade, não é usada por nenhum comando comum do UNIX. O fato de ser uma pronúncia incorreta de "obter" pode ou não ser relevante.
  • Estúpido. Desprezível e desprezível. Simples. Faça sua escolha no dicionário de gíria.
  • "Rastreador de informações globais": você está de bom humor e realmente funciona para você. Os anjos cantam e uma luz de repente enche a sala.
  • "Caminhão idiota maldito de merda": quando ele quebra.

Lançamentos

Lista de lançamentos Git:

Versão Data de lançamento original Versão mais recente (patch) Data de lançamento (do patch) Mudanças notáveis
Versão antiga, não mais mantida: 0,99 11/07/2005 0.99.9n 15/12/2005
Versão antiga, não mais mantida: 1.0 21/12/2005 1.0.13 27/01/2006
Versão antiga, não mais mantida: 1,1 08-01-2006 1.1.6 30/01/2006
Versão antiga, não mais mantida: 1,2 12/02/2006 1.2.6 08/04/2006
Versão antiga, não mais mantida: 1,3 18/04/2006 1.3.3 16/05/2006
Versão antiga, não mais mantida: 1,4 10/06/2006 1.4.4.5 16/07/2008
Versão antiga, não mais mantida: 1,5 14/02/2007 1.5.6.6 17/12/2008
Versão antiga, não mais mantida: 1,6 17/08/2008 1.6.6.3 15/12/2010
Versão antiga, não mais mantida: 1,7 13/02/2010 1.7.12.4 17/10/2012
Versão antiga, não mais mantida: 1.8 21/10/2012 1.8.5.6 17/12/2014
Versão antiga, não mais mantida: 1,9 14/02/2014 1.9.5 17/12/2014
Versão antiga, não mais mantida: 2.0 28/05/2014 2.0.5 17/12/2014
Versão antiga, não mais mantida: 2,1 16/08/2014 2.1.4 17/12/2014
Versão antiga, não mais mantida: 2,2 26/11/2014 2.2.3 04-09-2015
Versão antiga, não mais mantida: 2,3 05/02/2015 2.3.10 29/09/2015
Versão antiga, não mais mantida: 2,4 30/04/2015 2.4.12 05-05-2017
Versão antiga, não mais mantida: 2,5 27/07/2015 2.5.6 05-05-2017
Versão antiga, não mais mantida: 2,6 28/09/2015 2.6.7 05-05-2017
Versão antiga, não mais mantida: 2,7 04/10/2015 2.7.6 30/07/2017
Versão antiga, não mais mantida: 2,8 28/03/2016 2.8.6 30/07/2017
Versão antiga, não mais mantida: 2,9 13/06/2016 2.9.5 30/07/2017
Versão antiga, não mais mantida: 2,10 02/09/2016 2,10.5 22/09/2017
Versão antiga, não mais mantida: 2,11 29/11/2016 2.11.4 22/09/2017
Versão antiga, não mais mantida: 2,12 24/02/2017 2,12.5 22/09/2017
Versão antiga, não mais mantida: 2,13 10/05/2017 2,13.7 22/05/2018
Versão antiga, não mais mantida: 2,14 04/08/2017 2.14.6 07/12/2019
Versão antiga, não mais mantida: 2,15 30/10/2017 2.15.4 07/12/2019
Versão antiga, não mais mantida: 2,16 17/01/2018 2.16.6 07/12/2019
Versão mais antiga, mas ainda mantida: 2,17 02/04/2018 2.17.6 2021-03-09
Versão mais antiga, mas ainda mantida: 2,18 21/06/2018 2,18,5 2021-03-09
Versão mais antiga, mas ainda mantida: 2,19 10/09/2018 2.19.6 2021-03-09
Versão mais antiga, mas ainda mantida: 2,20 09/12/2018 2,20,5 2021-03-09
Versão mais antiga, mas ainda mantida: 2,21 24/02/2019 2.21.4 2021-03-09
Versão mais antiga, mas ainda mantida: 2,22 07/06/2019 2.22.5 2021-03-09
Versão mais antiga, mas ainda mantida: 2,23 16/08/2019 2.23.4 2021-03-09
Versão mais antiga, mas ainda mantida: 2,24 04/11/2019 2.24.4 2021-03-09
Versão mais antiga, mas ainda mantida: 2,25 2013-01-13 2,25,5 2021-03-09 Gerenciamento esparso de checkout facilitado
Versão mais antiga, mas ainda mantida: 2,26 22/03/2020 2.26.3 2021-03-09
  • A versão 2 do protocolo agora é o padrão
  • Alguns novos truques de configuração
  • Atualizações para git sparse-checkout

Versão mais antiga, mas ainda mantida: 2,27 01-06-2020 2.27.1 2021-03-09
Versão mais antiga, mas ainda mantida: 2,28 27/07/2020 2.28.1 2021-03-09
  • Apresentando init.defaultBranch
  • Filtro de Bloom de caminho alterado

Versão mais antiga, mas ainda mantida: 2,29 19/10/2020 2.29.3 2021-03-09
  • Suporte experimental SHA-256
  • Refspecs negativos
  • Novos git shortlogtruques

Versão mais antiga, mas ainda mantida: 2,30 27-12-2020 2,30,2 2021-03-09
  • Userdiff para atualização de PHP, Rust, atualização de CSS
  • O script de conclusão da linha de comando (em contrib /) aprendeu que "git stash show" leva as opções "git diff" leva.

Versão mais antiga, mas ainda mantida: 2,31 2021-03-15 2,31.1 2021-04-02
  • git difftooladiciona --skip-toopção
  • --format melhorias para leitura por máquina
  • git pull aviso para especificar rebase ou fusão

Versão mais antiga, mas ainda mantida: 2,32 06/06/2021
Versão estável atual: 2,33 2021-08-16
Lenda:
Versão antiga
Versão mais antiga, ainda mantida
Última versão
Versão de visualização mais recente
Lançamento futuro
Fontes:

Projeto

O design do Git foi inspirado no BitKeeper e no Monotone . Git foi originalmente projetado como um mecanismo de sistema de controle de versão de baixo nível, em cima do qual outros poderiam escrever front-ends, como Cogito ou StGIT . O projeto Git central desde então se tornou um sistema de controle de versão completo que pode ser usado diretamente. Embora fortemente influenciado pelo BitKeeper, Torvalds evitou deliberadamente as abordagens convencionais, levando a um design único.

Características

O design de Git é uma síntese da experiência de Torvalds com o Linux na manutenção de um grande projeto de desenvolvimento distribuído, junto com seu conhecimento íntimo de desempenho do sistema de arquivos obtido com o mesmo projeto e a necessidade urgente de produzir um sistema funcional em pouco tempo. Essas influências levaram às seguintes opções de implementação:

Forte suporte para desenvolvimento não linear
O Git oferece suporte a ramificações e mesclagens rápidas e inclui ferramentas específicas para visualizar e navegar em um histórico de desenvolvimento não linear. No Git, uma suposição básica é que uma mudança será mesclada com mais frequência do que é escrita, à medida que é repassada a vários revisores. No Git, branches são muito leves: um branch é apenas uma referência a um commit. Com seus compromissos parentais, toda a estrutura de ramificação pode ser construída.
Desenvolvimento distribuído
Como Darcs , BitKeeper , Mercurial , Bazaar e Monotone , Git dá a cada desenvolvedor uma cópia local do histórico de desenvolvimento completo, e as mudanças são copiadas de um repositório para outro. Essas alterações são importadas como ramificações de desenvolvimento adicionadas e podem ser mescladas da mesma maneira que uma ramificação desenvolvida localmente.
Compatibilidade com sistemas e protocolos existentes
Os repositórios podem ser publicados via protocolo de transferência de hipertexto (HTTP), protocolo de transferência de arquivo (FTP) ou protocolo Git por meio de um soquete simples ou Secure Shell (ssh). Git também tem uma emulação de servidor CVS, que permite o uso de clientes CVS existentes e plug-ins IDE para acessar repositórios Git. Os repositórios do Subversion podem ser usados ​​diretamente com git-svn.
Tratamento eficiente de grandes projetos
Torvalds descreveu o Git como sendo muito rápido e escalável, e os testes de desempenho feitos pela Mozilla mostraram que ele era uma ordem de magnitude mais rápido do que alguns sistemas de controle de versão; buscar o histórico da versão de um repositório armazenado localmente pode ser cem vezes mais rápido do que buscá-lo no servidor remoto.
Autenticação criptográfica da história
O histórico do Git é armazenado de tal forma que o ID de uma versão específica (um commit nos termos do Git) depende do histórico de desenvolvimento completo que conduz a esse commit. Uma vez publicado, não é possível alterar as versões anteriores sem que isso seja notado. A estrutura é semelhante a uma árvore Merkle , mas com dados adicionados nos nós e folhas. ( Mercurial e Monotone também têm essa propriedade.)
Design baseado em kit de ferramentas
Git foi projetado como um conjunto de programas escritos em C e vários scripts de shell que fornecem wrappers para esses programas. Embora a maioria desses scripts tenha sido reescrita em C para velocidade e portabilidade, o design permanece e é fácil encadear os componentes.
Estratégias de mesclagem plugáveis
Como parte do design de seu kit de ferramentas, o Git tem um modelo bem definido de uma mesclagem incompleta e vários algoritmos para completá-la, culminando em dizer ao usuário que não é possível concluir a mesclagem automaticamente e que a edição manual é necessária.
O lixo se acumula até ser coletado
Abortar operações ou restaurar alterações deixará objetos pendentes inúteis no banco de dados. Geralmente são uma pequena fração da história de crescimento contínuo de objetos desejados. O Git executará a coleta de lixo automaticamente quando objetos soltos suficientes forem criados no repositório. A coleta de lixo pode ser chamada explicitamente usando git gc.
Empacotamento periódico de objetos explícitos
Git armazena cada objeto recém-criado como um arquivo separado. Embora compactado individualmente, ocupa muito espaço e é ineficiente. Isso é resolvido pelo uso de pacotes que armazenam um grande número de objetos compactados em delta entre si em um arquivo (ou fluxo de bytes de rede) chamado packfile . Os pacotes são compactados usando a heurística de que os arquivos com o mesmo nome são provavelmente semelhantes, sem depender disso para correção. Um arquivo de índice correspondente é criado para cada packfile, informando o deslocamento de cada objeto no packfile. Objetos recém-criados (com histórico recém-adicionado) ainda são armazenados como objetos únicos, e a reembalagem periódica é necessária para manter a eficiência do espaço. O processo de empacotar o repositório pode ser muito caro do ponto de vista computacional. Ao permitir que os objetos existam no repositório em um formato solto, mas gerado rapidamente, o Git permite que a operação de pacote cara seja adiada para mais tarde, quando o tempo importa menos, por exemplo, o fim de um dia de trabalho. O Git faz o reempacotamento periódico automaticamente, mas o reempacotamento manual também é possível com o git gccomando. Para integridade de dados, o packfile e seu índice têm uma soma de verificação SHA-1 dentro, e o nome do arquivo do packfile também contém uma soma de verificação SHA-1. Para verificar a integridade de um repositório, execute o git fsckcomando.

Outra propriedade do Git é que ele captura as árvores de diretório de arquivos. Os primeiros sistemas para rastrear versões do código-fonte, Source Code Control System (SCCS) e Revision Control System (RCS), trabalharam em arquivos individuais e enfatizaram a economia de espaço obtida com deltas intercalados (SCCS) ou codificação delta (RCS). (em sua maioria semelhantes) versões. Os sistemas de controle de revisão posteriores mantiveram essa noção de um arquivo com uma identidade em várias revisões de um projeto. No entanto, Torvalds rejeitou esse conceito. Conseqüentemente, o Git não registra explicitamente os relacionamentos de revisão de arquivo em qualquer nível abaixo da árvore do código-fonte.

Essas relações de revisão implícitas têm algumas consequências significativas:

  • É um pouco mais caro examinar o histórico de alterações de um arquivo do que de todo o projeto. Para obter um histórico de mudanças que afetam um determinado arquivo, o Git deve percorrer o histórico global e então determinar se cada mudança modificou aquele arquivo. Este método de examinar o histórico, entretanto, permite que o Git produza com igual eficiência um único histórico mostrando as mudanças em um conjunto arbitrário de arquivos. Por exemplo, um subdiretório da árvore de origem mais um arquivo de cabeçalho global associado é um caso muito comum.
  • As renomeações são tratadas implicitamente em vez de explicitamente. Uma reclamação comum com o CVS é que ele usa o nome de um arquivo para identificar seu histórico de revisão, portanto, mover ou renomear um arquivo não é possível sem interromper seu histórico ou renomear o histórico e, portanto, tornar o histórico impreciso. A maioria dos sistemas de controle de revisão pós-CVS resolve isso dando a um arquivo um nome de longa duração exclusivo (análogo a um número de inode ) que sobrevive à renomeação. O Git não registra tal identificador, e isso é reivindicado como uma vantagem. Os arquivos de código-fonte às vezes são divididos ou mesclados, ou simplesmente renomeados, e registrar isso como uma simples renomeação congelaria uma descrição imprecisa do que aconteceu no histórico (imutável). Git soluciona o problema detectando renomeações enquanto navega no histórico de instantâneos, em vez de gravá-lo ao fazer o instantâneo. (Resumidamente, dado um arquivo na revisão N , um arquivo com o mesmo nome na revisão N  - 1 é seu ancestral padrão. No entanto, quando não há nenhum arquivo com o mesmo nome na revisão N  - 1, o Git procura por um arquivo que existia apenas na revisão N  - 1 e é muito semelhante ao novo arquivo.) No entanto, requer mais trabalho intensivo da CPU cada vez que o histórico é revisado, e várias opções para ajustar as heurísticas estão disponíveis. Esse mecanismo nem sempre funciona; às vezes, um arquivo que é renomeado com mudanças no mesmo commit é lido como uma exclusão do arquivo antigo e a criação de um novo arquivo. Os desenvolvedores podem contornar essa limitação confirmando a renomeação e as alterações separadamente.

Git implementa várias estratégias de fusão; uma estratégia não padrão pode ser selecionada no momento da fusão:

  • resolver : o algoritmo de mesclagem tradicional de três vias .
  • recursivo : Este é o padrão ao extrair ou mesclar um ramo e é uma variante do algoritmo de mesclagem de três vias.

    Quando há mais de um ancestral comum que pode ser usado para uma mesclagem de três vias, ele cria uma árvore mesclada dos ancestrais comuns e a usa como a árvore de referência para a mesclagem de três vias. Foi relatado que isso resultou em menos conflitos de mesclagem sem causar mesclagens incorretas por testes feitos em commits de mesclagem anteriores retirados do histórico de desenvolvimento do kernel do Linux 2.6. Além disso, pode detectar e tratar mesclagens envolvendo renomeações.

    -  Linus Torvalds
  • polvo : Este é o padrão ao mesclar mais de duas cabeças.

Estruturas de dados

Os primitivos do Git não são inerentemente um sistema de gerenciamento de código-fonte . Torvalds explica:

De muitas maneiras, você pode apenas ver o git como um sistema de arquivos - é endereçável por conteúdo e tem uma noção de controle de versão, mas eu realmente o projetei considerando o problema do ponto de vista de uma pessoa do sistema de arquivos (ei, kernels é o que eu faço) e, na verdade, não tenho absolutamente nenhum interesse em criar um sistema SCM tradicional.

A partir dessa abordagem de design inicial, o Git desenvolveu o conjunto completo de recursos esperados de um SCM tradicional, com recursos principalmente sendo criados conforme necessário, depois refinados e estendidos ao longo do tempo.

Alguns fluxos de dados e níveis de armazenamento no sistema de controle de revisão Git

O Git tem duas estruturas de dados : um índice mutável (também chamado de estágio ou cache ) que armazena informações sobre o diretório de trabalho e a próxima revisão a ser submetida; e um banco de dados de objetos imutável apenas para acréscimos .

O índice serve como um ponto de conexão entre o banco de dados de objetos e a árvore de trabalho.

O banco de dados de objetos contém cinco tipos de objetos:

  • Um blob ( objeto binário grande ) é o conteúdo de um arquivo . Os blobs não têm nome de arquivo adequado, carimbos de data / hora ou outros metadados (o nome de um blob internamente é um hash de seu conteúdo). No git, cada blob é uma versão de um arquivo, ele contém os dados do arquivo.
  • Um objeto de árvore é o equivalente a um diretório. Ele contém uma lista de nomes de arquivos, cada um com alguns bits de tipo e uma referência a um blob ou objeto de árvore que é aquele arquivo, link simbólico ou conteúdo do diretório. Esses objetos são um instantâneo da árvore de origem. (No total, isso compreende uma árvore Merkle , o que significa que apenas um único hash para a árvore raiz é suficiente e realmente usado em commits para apontar com precisão o estado exato de estruturas de árvore inteiras de qualquer número de subdiretórios e arquivos.)
  • Um objeto de confirmação vincula objetos de árvore no histórico. Ele contém o nome de um objeto de árvore (do diretório de origem de nível superior), um registro de data e hora, uma mensagem de log e os nomes de zero ou mais objetos de confirmação pai.
  • Um objeto de tag é um contêiner que contém uma referência a outro objeto e pode conter metadados adicionados relacionados a outro objeto. Mais comumente, é usado para armazenar uma assinatura digital de um objeto commit correspondente a uma liberação particular dos dados sendo rastreados pelo Git.
  • Um objeto packfile é uma versão zlib compactada de vários outros objetos para compactação e facilidade de transporte em protocolos de rede.

Cada objecto é identificado por um SHA-1 de hash do seu conteúdo. Git calcula o hash e usa esse valor para o nome do objeto. O objeto é colocado em um diretório que corresponde aos dois primeiros caracteres de seu hash. O resto do hash é usado como nome de arquivo para esse objeto.

O Git armazena cada revisão de um arquivo como um blob único. Os relacionamentos entre os blobs podem ser encontrados examinando a árvore e os objetos de confirmação. Os objetos recém-adicionados são armazenados em sua totalidade usando a compactação zlib . Isso pode consumir uma grande quantidade de espaço em disco rapidamente, portanto, os objetos podem ser combinados em pacotes , que usam compactação delta para economizar espaço, armazenando blobs como suas alterações em relação a outros blobs.

Além disso, o git armazena rótulos chamados refs (abreviação de referências) para indicar os locais de vários commits. Eles são armazenados no banco de dados de referência e são, respectivamente:

  • Heads (branches) : Referências nomeadas que são avançadas automaticamente para o novo commit quando um commit é feito em cima deles.
  • HEAD : Um head reservado que será comparado com a árvore de trabalho para criar um commit.
  • Tags : como referências de branch, mas fixadas em um commit específico. Usado para rotular pontos importantes da história.

Referências

Cada objeto no banco de dados Git que não é referido pode ser limpo usando um comando de coleta de lixo ou automaticamente. Um objeto pode ser referenciado por outro objeto ou uma referência explícita. Git conhece diferentes tipos de referências. Os comandos para criar, mover e excluir referências variam. "git show-ref" lista todas as referências. Alguns tipos são:

  • heads : refere-se a um objeto localmente,
  • remotes : refere-se a um objeto que existe em um repositório remoto,
  • stash : refere-se a um objeto ainda não confirmado,
  • meta : por exemplo, uma configuração em um repositório vazio, direitos do usuário; o namespace refs / meta / config foi introduzido retrospectivamente, é usado por Gerrit ,
  • tags : veja acima.

Implementações

gitg é um front-end gráfico usando GTK + .

Git (a implementação principal em C) é desenvolvido principalmente no Linux , embora também suporte a maioria dos principais sistemas operacionais, incluindo BSD , Solaris , macOS e Windows .

As janelas do primeiro porto de Git foi principalmente um quadro Linux de emulação que hospeda a versão Linux. A instalação do Git no Windows cria um diretório de arquivos de programas com nome semelhante, contendo a porta Mingw-w64 da coleção de compiladores GNU , Perl 5, MSYS2 (em si uma bifurcação do Cygwin , um ambiente de emulação semelhante ao Unix para Windows) e várias outras portas ou emulações do Windows de utilitários e bibliotecas do Linux. Atualmente, compilações nativas do Git para Windows são distribuídas como instaladores de 32 e 64 bits. O site oficial do git atualmente mantém uma versão do Git para Windows, ainda usando o ambiente MSYS2.

A implementação JGit do Git é uma biblioteca de software Java pura , projetada para ser incorporada em qualquer aplicativo Java. JGit é usado na ferramenta de revisão de código Gerrit e em EGit, um cliente Git para o IDE Eclipse .

Go-git é uma implementação de código aberto do Git escrito em Go puro . Atualmente é usado para apoiar projetos como uma interface SQL para repositórios de código Git e fornecer criptografia para Git.

A implementação de Dulwich do Git é um componente de software Python puro para Python 2.7, 3.4 e 3.5.

A implementação libgit2 do Git é uma biblioteca de software ANSI C sem outras dependências, que pode ser construída em várias plataformas, incluindo Windows, Linux, macOS e BSD. Ele possui ligações para muitas linguagens de programação, incluindo Ruby , Python e Haskell .

JS-Git é uma implementação JavaScript de um subconjunto do Git.

GUIs Git

Servidor Git

Captura de tela da interface do Gitweb mostrando uma comparação de commit

Como o Git é um sistema de controle de versão distribuído, ele pode ser usado como um servidor pronto para uso. É fornecido com um comando embutido git daemonque inicia um servidor TCP simples rodando no protocolo GIT. Servidores HTTP Git dedicados ajudam (entre outros recursos) adicionando controle de acesso, exibindo o conteúdo de um repositório Git por meio de interfaces da web e gerenciando vários repositórios. Repositórios Git já existentes podem ser clonados e compartilhados para serem usados ​​por outros como um repositório centralizado. Ele também pode ser acessado via shell remoto apenas com o software Git instalado e permitindo que um usuário faça login. Os servidores Git normalmente ouvem na porta TCP 9418.

Código aberto

  • Hospedar o servidor Git usando o Git Binary.
  • Gerrit , um servidor git configurável para suportar revisões de código e fornecer acesso via ssh, um Apache MINA ou OpenSSH integrado, ou um servidor web Jetty integrado . Gerrit fornece integração para certificados de cliente LDAP, Active Directory, OpenID, OAuth, Kerberos / GSSAPI, X509 https. Com o Gerrit 3.0, todas as configurações serão armazenadas como repositórios git, nenhum banco de dados necessário para ser executado. Gerrit tem um recurso pull-request implementado em seu núcleo, mas carece de uma GUI para ele.
  • Phabricator , um spin-off do Facebook. Como o Facebook usa principalmente o Mercurial , o suporte ao git não é tão proeminente.
  • RhodeCode Community Edition (CE), suportando git, Mercurial e Subversion com uma licença AGPLv3 .
  • Kallithea , com suporte para git e Mercurial , desenvolvido em Python com licença GPL .
  • Projetos externos como gitolite, que fornecem scripts sobre o software git para fornecer controle de acesso refinado.
  • Existem várias outras soluções FLOSS para auto-hospedagem, incluindo Gogs e Gitea , um fork do Gogs, ambos desenvolvidos na linguagem Go com licença MIT .

Servidor Git como serviço

Existem muitas ofertas de repositórios Git como um serviço. Os mais populares são GitHub , SourceForge , Bitbucket e GitLab .

Adoção

A Eclipse Foundation relatou em sua pesquisa anual com a comunidade que, em maio de 2014, o Git é agora a ferramenta de gerenciamento de código-fonte mais amplamente usada, com 42,9% dos desenvolvedores de software profissionais relatando que usam Git como seu sistema de controle de origem principal em comparação com 36,3 % em 2013, 32% em 2012; ou para respostas Git excluindo o uso de GitHub : 33,3% em 2014, 30,3% em 2013, 27,6% em 2012 e 12,8% em 2011. O diretório de código aberto Black Duck Open Hub relata uma aceitação semelhante entre os projetos de código aberto.

O Stack Overflow incluiu o controle de versão em sua pesquisa anual de desenvolvedores em 2015 (16.694 respostas), 2017 (30.730 respostas) e 2018 (74.298 respostas). Git foi o grande favorito dos desenvolvedores respondentes nessas pesquisas, relatando até 87,2% em 2018.

Sistemas de controle de versão usados ​​por desenvolvedores de resposta:

Nome 2015 2017 2018
Git 69,3% 69,2% 87,2%
Subversão 36,9% 9,1% 16,1%
TFVC 12,2% 7,3% 10,9%
Mercurial 7,9% 1,9% 3,6%
CVS 4,2%
Perforce 3,3%
VSS 0,6%
ClearCase 0,4%
Backups de arquivo zip 2,0% 7,9%
Compartilhamento de rede bruta 1,7% 7,9%
De outros 5,8% 3,0%
Nenhum 9,3% 4,8% 4,8%

O site de empregos de TI do Reino Unido, itjobswatch.co.uk, relata que, no final de setembro de 2016, 29,27% das vagas de desenvolvimento de software permanentes no Reino Unido citaram Git, à frente de 12,17% para Microsoft Team Foundation Server , 10,60% para Subversion , 1,30% para Mercurial e 0,48% para Visual SourceSafe .

Extensões

Existem muitas extensões Git , como Git LFS , que começou como uma extensão do Git na comunidade GitHub e agora é amplamente usado por outros repositórios. As extensões são geralmente desenvolvidas de forma independente e mantidas por pessoas diferentes, mas em algum ponto no futuro, uma extensão amplamente usada pode ser mesclada ao Git.

Outras extensões git de código aberto incluem:

A Microsoft desenvolveu a extensão Virtual File System for Git (VFS for Git; anteriormente Git Virtual File System ou GVFS) para lidar com o tamanho da árvore de código-fonte do Windows como parte de sua migração de 2017 do Perforce . O VFS para Git permite que os repositórios clonados usem espaços reservados cujo conteúdo é baixado apenas quando um arquivo é acessado.

Convenções

O Git não impõe muitas restrições sobre como deve ser usado, mas algumas convenções são adotadas para organizar histórias, especialmente aquelas que requerem a cooperação de muitos colaboradores.

  • O branch principal (antigo branch master ) é criado por padrão com git init e é freqüentemente usado como o branch no qual outras mudanças são mescladas. Correspondentemente, o nome padrão do remoto upstream é origin e, portanto, o nome do branch remoto padrão é origin / main . Embora o nome master fosse comum antes do final de 2020, o Software Freedom Conservancy e o projeto Git reconheceram suas deficiências e começaram a procurar uma alternativa em junho de 2020. Projetos associados seguiram o exemplo: do final de 2020 em diante, novos repositórios GitHub nomeiam o branch padrão principal , e de meados de 2021 em diante, novos repositórios GitLab fazem o mesmo.
  • Os commits enviados normalmente não devem ser sobrescritos, mas sim revertidos (um commit é feito no topo que reverte as mudanças para um commit anterior). Isso evita que novos commits compartilhados baseados em commits compartilhados sejam inválidos porque o commit no qual eles são baseados não existe no remoto. Se os commits contêm informações confidenciais, eles devem ser removidos, o que envolve um procedimento mais complexo para reescrever o histórico.
  • O fluxo de trabalho git-flow e as convenções de nomenclatura são frequentemente adotados para distinguir históricos instáveis ​​específicos de recursos (feature / *), históricos compartilhados instáveis ​​(desenvolver), históricos prontos para produção (principal) e patches de emergência para produtos lançados (hotfix).
  • As solicitações pull não são um recurso do git, mas normalmente são fornecidas pelos serviços de nuvem git. Uma solicitação pull é uma solicitação de um usuário para mesclar um branch de seu fork do repositório em outro repositório que compartilha o mesmo histórico (chamado de upstream remote). A função subjacente de uma solicitação pull não é diferente daquela de um administrador de um repositório que extrai alterações de outro remoto (o repositório que é a origem da solicitação pull). No entanto, a própria solicitação pull é um tíquete gerenciado pelo servidor de hospedagem que inicia scripts para executar essas ações; não é um recurso do git SCM.

Segurança

O Git não fornece mecanismos de controle de acesso, mas foi projetado para operar com outras ferramentas especializadas em controle de acesso.

Em 17 de dezembro de 2014, um exploit foi encontrado afetando as versões Windows e macOS do cliente Git. Um invasor pode executar a execução arbitrária de código em um computador de destino com Git instalado, criando uma árvore Git maliciosa (diretório) chamada .git (um diretório em repositórios Git que armazena todos os dados do repositório) em um caso diferente (como .GIT ou .Git, necessário porque o Git não permite que a versão em minúsculas de .git seja criada manualmente) com arquivos maliciosos no subdiretório .git / hooks (uma pasta com arquivos executáveis ​​que o Git executa) em um repositório feito pelo invasor ou em um repositório que o invasor pode modificar. Se um usuário do Windows ou Mac puxar (baixar) uma versão do repositório com o diretório malicioso e, em seguida, alternar para esse diretório, o diretório .git será sobrescrito (devido ao traço que não diferencia maiúsculas de minúsculas dos sistemas de arquivos do Windows e Mac) e o arquivos executáveis ​​maliciosos em .git / hooks podem ser executados, o que resulta na execução dos comandos do invasor. Um invasor também pode modificar o arquivo de configuração .git / config , que permite ao invasor criar aliases Git maliciosos (aliases para comandos Git ou comandos externos) ou modificar aliases existentes para executar comandos maliciosos quando executados. A vulnerabilidade foi corrigida na versão 2.2.1 do Git, lançada em 17 de dezembro de 2014 e anunciada no dia seguinte.

Git versão 2.6.1, lançado em 29 de setembro de 2015, continha um patch para uma vulnerabilidade de segurança ( CVE - 2015-7545 ) que permitia a execução de código arbitrário. A vulnerabilidade poderia ser explorada se um invasor pudesse convencer a vítima a clonar um URL específico, já que os comandos arbitrários foram incorporados ao próprio URL. Um invasor pode usar a exploração por meio de um ataque man-in-the-middle se a conexão não estiver criptografada, pois ele pode redirecionar o usuário para um URL de sua escolha. Os clones recursivos também eram vulneráveis, pois permitiam ao controlador de um repositório especificar URLs arbitrários por meio do arquivo gitmodules.

Git usa hashes SHA-1 internamente. Linus Torvalds respondeu que o hash era principalmente para proteger contra corrupção acidental, e a segurança que um hash criptograficamente seguro oferece era apenas um efeito colateral acidental, com a segurança principal sendo assinada em outro lugar. Desde uma demonstração do ataque SHAttered contra git em 2017, o git foi modificado para usar uma variante SHA-1 resistente a este ataque. Um plano para a transição da função hash está sendo escrito desde fevereiro de 2020.

Marca comercial

"Git" é uma marca comercial registrada da Software Freedom Conservancy sob US500000085961336 desde 03/02/2015 .

Veja também

Notas

Referências

links externos