Git - Object Store

O object store, descrito no último post, é a parte principal da implementação do repositório do Git. Ele contém os arquivos de dados original e todas as mensagens de log, informações do autor, datas e outras informações requeridas para gerar qualquer versão ou branch do projeto.

Dentro do objecto store há apenas quatro tipos de objetos, a saber:

                    

• Blobs (binary large object) que representa cada versão de um arquivo. Esse tipo de objeto pode conter qualquer dado. Um blob contém dados de um arquivo, mas não contém quaisquer metadados sobre ele nem mesmo o seu nome.
• Tree que representa o primeiro nível de um diretório. Ele registra identificadores para blob, nome de caminhos, e um pouco dos metadados de todos os arquivos e diretórios. Além disso, ele pode fazer referência a outros objetos tree, de forma recursiva, criando assim, um hierarquia completa de arquivos e subdiretórios.
• Um objeto commit mantém metadados para cada mudança introduzidas no repositório, incluindo o autor, quem fez a submissão, data de quando foi feita a submissão e mensagens de log. Cada commit aponta para um objeto da árvore que captura um snapshot completo, o estado do repositório no momento em que a submissão foi realizada.
• Um objeto tag atribui um nome arbitrário, porém legível,  a um objeto específico, geralmente um commit. Embora 9dfdsf3dfgfd435fds3333deaaaf5169 se refira a uma exata e bem definida committer, um nome de tag  mais familiar como Ver-1.0-Alpha poder fazer mais sentido.

 Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013

Git - Conceitos Básicos

Neste post, iremos descrever alguns dos conceitos comuns aos Sistemas de Controle de Versão(SCV), porém na visão do Git.

Um repositório Git nada mais é do que uma simples base de dados que contém todas as informações necessárias para manter e gerenciar o histórico e revisões de um projeto. No Git, como na maioria dos sistemas de controle de versão, um repositório mantém uma cópia completa de todo um projeto, em cada etapa do seu ciclo de vida. Entretanto, diferentemente de outros SCVs, repositório Git não só fornece uma cópia completa de trabalho de todos os arquivos no repositório, mas também uma cópia do repositório com a qual se está trabalhando.

Git mantém um conjunto de valores de configuração dentro de cada repositório (como nome do usuário do repositório e endereço de e-mail). Ao contrário dos dados de arquivo e outros metadados do repositório, as configurações não são propagadas a partir de um repositório para outro durante uma operação de clone ou duplicação.

Dentro de um repositório, o Git mantém duas estruturas de dados primárias, o object store e o index. Todos esses repositórios de dados são armazenados na raiz do seu diretório de trabalho, em um subdiretório oculto chamado .git.

O object store  é projetado para ser copiado, de maneira eficiente, durante uma operação de clone como parte do mecanismo que suporta um SCVs totalmente distribuídos. O index é uma informação transitória, é privado de um repositório, e pode ser criada ou modificada sob demanda quando necessário.

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

ClearCase - Uma introdução

O ClearCase é uma solução de gerenciamento de configuração de software da família Rational da IBM. Uma das suas funcionalidades é o controle de versão, mas ela é composta também pelo gerenciamento de área de trabalho, suporte para desenvolvimento paralelo, segurança de IP efetiva e auditoria de compilação. Assim como grande parte das soluções das IBM, ela é uma solução paga. Entretanto é uma solução poderosa e flexível. Ela pode ser implantada em qualquer tamanho de equipe, desde um pequeno grupo até equipes grandes e geograficamente distribuídas. Ele pode ser implantado em servidores linux ou windows e exige um browser como um meio de acesso a aplicação.

• Controle de versão e gerenciamento de área de trabalho — Gerencia arquivos, diretórios e outros recursos de desenvolvimento durante o ciclo de vida.
• Gerenciamento de mudança colaborativo integrado — Gerencia problemas e mudanças na resolução.
• Desenvolvimento paralelo avançado — Inclui ramificação automática, fusão avançada e tecnologia diferenciada.
• Segurança de IP efetiva — Oferece assinaturas eletrônicas, autenticação de usuário para acesso seguro e controlado e trilhas de auditoria para ajudar a atender aos requisitos de conformidade e de controle.
• Auditoria de compilação confiável — Ajuda a simplificar o ciclo de edição-compilação-depuração e reproduz versões de software.

Git - Uma introdução

O Git é um sistema de controle de versão que teve seu primeiro protótipo lançado em abril de 2005. Idealizado por Linus Torvalds, criado do Linux, ele foi projetado para evitar falhas encontradas na maiorias dos sistemas de controle de versão.

Adaptado para melhor velocidade, desempenho, flexibilidade e facilidade de uso, ele trás como premissa as seguintes características:

• Atomicidade, que garante a unicidade de uma operação. Desta forma, ele evita, por exemplo, a perda de dados ou incompatibilidade de versão devido a operações parciais.
• Performance, que garante velocidade para lidar com milhões de arquivos. Conceitualmente, a maioria dos outros sistemas de controle de versão (Subversion, CVS, etc), veem seus dados como um conjunto de arquivos e as mudanças em cada um deles como uma versão contínua. A figura abaixo representa como os outros sistemas tratam arquivos e suas versões:

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide.

Diferentemente, o Git toma um snapshot (fotografia) de todo o conjunto de arquivos ao invés de armazenar apenas a diferença entre as versões de cada arquivo. Isso, contribui com a velocidade em determinadas operações como, por exemplo, reverter o conteúdo de seu arquivo de versões anteriores. Cada vez que uma versão é criada um snapshot é tirado. Isso não significa que o Git armazena várias réplicas de seus arquivos. Se ele descobre que não há nenhuma mudança em qualquer um dos conteúdos dos seus arquivos, apenas uma referência para o arquivo que aponta para o snapshot anterior é armazenado no novo snapshot.  A figura abaixo, ilustra esse processo:

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide.

• Segurança, que garante que ninguém possa adulterar o conteúdo dos seus arquivos. O Git utiliza um hash SHA-1 em suas operações. Isso significa que é impossível mudar o conteúdo de qualquer arquivo ou diretório, sem que seja possível tomar conhecimento dessas alterações.

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.

Conceitos, termos e abreviações

Quando lidamos com Sistemas de Controle de Versão, é necessário o conhecimento dos seus principais conceitos, termos e abreviações, os quais listamos abaixo:

artefato	Qualquer produto do ciclo de produção do projeto, podendo ser arquivos eletrônicos de código-fonte, arquivos eletrônicos de código compilado, a reunião desses arquivos, arquivos de documentação ou mesmo objetos físicos, como manuais impressos ou discos de instalação
repositório	Sistema de controle de versões de artefatos eletrônicos em que os itens de configuração eletrônicos são armazenados com a garantia de possibilidade de reversão a uma versão anterior do item
SCV	Sistema de Controle de Versões
baseline	Conjunto de artefatos aprovados e revisados que serão utilizados para atividades posteriores. É definida pela gerência de projeto como base para evoluções e desenvolvimento futuro
branch	Linha de desenvolvimento paralela à linha principal do repositório de código-fonte e documentação
tag	Rótulo de identificação de um conjunto de itens de configuração que representa um todo de interesse. Ordinariamente, as versões de release e as baselines são identificadas com tags para melhor referência
trunk/master	Linha principal de desenvolvimento existente no repositório
merge	Operação de integração de alterações de um determinado branch (ramo) ao trunk ou a outro branch
release	Versão do sistema validada para instalação, seja em produção, seja para homologação. Conjunto de itens enviado a um tribunal ou a um departamento para instalação, que não deve conter o código-fonte do sistema. Cada release pode encerrar novas funcionalidades ou mudanças decorrentes de evolução do sistema
commit	Submeter ao sistema de controle de versão alterações em um conjunto de arquivos
checkout	Copiar uma versão dos arquivos do sistema de controle de versão. Geralmente esta operação copia a última versão dos arquivos e, em alguns SCVs, o checkout inclui metadados necessários para o próximo commit.

Tipos de controle de versão - Parte 3

No post passado foi descrito o uso do sistema de controle de versão centralizado. Com essa abordagem é possível disponibilizar arquivos (e seus históricos) para uma equipe de trabalho. Esses arquivos ficam em um servidor que é acessado por todos os integrantes, que mantém em suas estações de trabalho uma cópia da última versão dos arquivos trabalhados.

Mas o que aconteceria se esse servidor ficasse fora do ar? Ou por algum motivo os arquivos fossem perdidos ?

Visando resolver essa questão, foram criados os sistemas de controle de versão distribuídos que funcionam como um híbrido entre o local e centralizado.  Nesse tipo de sistema de controle, os arquivos e seus históricos são mantidos tanto no servidor quanto nas máquinas clientes.

Um sistema de controle de versão distribuído é projetado para funcionar em ambos os sentidos. Ele armazena toda o histórico do arquivo/arquivos em cada máquina local e também sincroniza as alterações locais feitas pelo usuário para o servidor sempre que necessário. Assim, as alterações podem ser compartilhados com outras pessoas proporcionando um ambiente de trabalho colaborativo.

De modo geral, em um sistema distribuído de controle de versão é possível ter os benefícios dos dois mundos. Além disso, existem várias outras vantagens em termos de desempenho, facilidade de uso e administração.

As figuras a seguir mostram os três tipos de sistemas de controle de versão apresentados neste blog.

Sistema de Controle de Versão Centralizado

Sistema de Controle de Versão Centralizado

Sistema de Controle de Versão Distribuído

Fonte: SOMASUNDARAM, R. Git: Version Control for Everyone Beginner's Guide. Birmingham - Mumbai: Packt Publishing Ltd, 2013.