GIT

Juliana Jenny Kolb

Home > Simulados on-line  > Questões de Concursos > Tecnologia da Informação (TI)

GIT

Git  é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte, com ênfase em velocidade. 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 é 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.

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. 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. 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.

Estratégias de mescla (merge) conectáveis

Como parte de desenho em ferramentas, o Git tem um conjunto bem definido de modelos de uma mescla incompleta, e possuí vários algoritimos para completá-las, culminando em comunicar ao usuário que é incapaz de completar o merge automaticamente, sendo necessária uma edição manual.

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:

• É pouco mais dispendioso examinar o histórico de um único arquivo do que o histórico de todo o projeto. Para obter o histórico de mudanças de um arquivo, Git precisa caminhar pelo histórico global e então verificar qual mudança modificou aquele arquivo. Este método de examinar o histórico faz, porém, com que o Git produza igual eficiência em mostrar um histórico de mudanças de um ou de vários arquivos arbitrários. Por exemplo, é comum o caso de um subdiretório da árvore de arquivos fontes mais um arquivo global de cabeçalho associado.
• Renomeação de arquivos são feitos de forma implícita. Uma queixa comum no CVS é que este usa o nome do arquivo para identificar o seu histórico de revisões. Então, não é possível mover ou renomear um arquivo sem interromper ou renomear seu histórico,o que, consequentemente, faz com que o histórica seja impreciso. A maioria dos controles de revisão pós-CVS resolve este problema por dar um tipo de identidade por nome único invariável para cada arquivo (um tipo de nó-i) que continua mesmo após renomeações. O Git não salva este tipo de identificador, e isso é uma vantagem alegada por Torvalds. Arquivos de código fonte, às vezes, são divididos, mesclados ou simplesmente renomeados.Salvar todas estas mudanças como simples renomes poderia congelar uma descrição imprecisa do que aconteceu na história real do mesmo (que é imutável). Git resolve este problema por detectar renomes enquanto navega pela história dos estados invés de gravá-los quando o estado é criado. (Para ser breve, dado um arquivo numa revisão N, um arquivo de mesmo nome numa revisão N-1 é seu ancestral comum. Porém, quando não existe arquivo com um nome parecido na revisão N-1, o Git procura por um arquivo que existiu apenas na revisão N-1 e que era similar ao arquivo novo). No entanto, não é necessário mais tempo de processamento intensivo toda vez que o histórico é revisado. Existem também numerosas opções para ajustar estas heurísticas.

O Git implementa várias estratégias de merge (mescla de arquivos); uma não padrão pode ser selecionada durante um merge:

• resolve (resolver): o tradicional algoritmo de merge em três vias.
• recursive (recursivo): Este é o padrão quando baixando ou mesclando um branch, uma variante do algoritmo de mescla em três vias. Quando há mais de um ancestral comum que pode ser usado em um merge de três vias, cria-se uma árvore de merge dos ancestrais comuns e usa-se isso como a árvore de referência para o merge em três vias. Isto têm resultado em menor número de conflitos em merges sem causar merges errados por testes realizados em merges tirados do histórico de desenvolvimento do kernel do Linux 2.6. Adicionalmente pode detectar e lidar com merges envolvendo renomeações.”
• octopus (polvo): Este é o padrão quando efetuado merge em mais de duas heads.