Orientação - Controlar as mudanças feitas no código

GitLab é a plataforma de hospedagem de código-fonte utilizada para controle de versão do sistema Redome. Ele permite que programadores, utilitários ou qualquer usuário cadastrado na plataforma contribuam para o desenvolvimento do sistema Redome de qualquer lugar, além de promover fácil comunicação através de recursos que registram issues ou permitem o merge de repositórios remotos (issues, pull request).

Conceitos Básicos

Com apenas pouco tempo de Git já é possível notar a presença de longas cadeias hexadecimais por toda parte. Essas cadeias são o resultado da função de hash SHA-1 que resulta em 40 casas hexadecimais. Elas são de extrema importância, visto que Git é em essência um repositório de objetos em que cada sequência SHA-1 mapeia a um objeto. Como em um dicionário Python, uma hash Perl ou HashMap Java, é esse número que nos leva ao objeto desejado.

Informações e meta-informações do repositório git são em geral armazenadas em objetos no diretorio ".git/objects" (exceto no caso de compactação). Esses objetos podem ser de vários tipos: blobs, trees, commits e tags. Os blobs como em base de dados SQL são capazes de armazenar qualquer tipo de informação como por exemplo o contudo de um arquivo. Já o objeto tree é muito semelhante a um diretório, podendo apontar para globs e recursivamente para outros objetos trees. Os outros dois últimos objetos estão mais relacionados às meta-informações do controle de versão. É sabido que cada commit representa uma foto do estado do repositório. Por isso, cada um deles aponta para um objeto do tipo tree cujas entradas são blobs representando o conteúdo dos arquivos naquele momento ou outros trees representando os diretórios do repositório e assim recursivamente. Por fim, tem-se o objeto tag que permite fazer uma referência a um commit, por exemplo, usando uma string mais amigável do que o SHA-1.

Como cada um dos objetos vistos anteriormente possui um hash associado fica claro que ele desempenha um papel fundamental no Git, mesmo que nem sempre o manipulamos diretamente. Lidar com um número hexadecimal de 40 dígitos pode não ser muito prático, por isso existe a liberdade de utilizar seus prefixos. Mesmo assim, pode ser mais interessante lidar com uma referência textual. Para cada uma das cabeças de desenvolvimento a funcionalidade de branches desempenha esse papel. Uma branch nada mais é do que um ponteiro para um commit cabeça. Como todo ponteiro que se preze, ele precisa armazenar um endereço, que no caso de Git é o SHA-1. Se inspecionarmos o conteúdo do ponteiro master de um repositório é possível notar a presença do hash. Na nomeclatura de Git denomina-se revisão (rev) um referência arbitrária a um commit, seja por hash, por nome de branch ou qualquer outra forma.

A estrutura de Branches

Git é um sistema de controle de versão reconhecidamente poderoso e flexível. Devido a sua natureza distribuída em que o desenvolvimento ocorre paralelamente em múltiplas branches, é de suma importância saber como combinar os múltiplos commits com toda a flexibilidade possível.

Master/Origin -> Branch utilizada para gerar versão no ambiente de homologação.

Hotfix -> Branch utilizada no caso de erros que estejam em produção. Esta deriva da Master/Origin.

Develop -> Esta será a branch de trabalho.

Regras diárias do fluxo de versionamento a ser seguido pela equipe

A ferramenta visual escolhida para utilização do GIT foi o TortoiseGIT.

1. Fazer o pull no início do dia, antes de cada commit e/ou quando julgar necessário.;
2. Os commits devem ser curtos e sem bugs e, preferencialmente, devem estar disponíveis na branch remota no final do dia.

A seguir um passo-a-passo sobre como realizar as tarefas diárias.

PULL

Utilizado para "baixar" o conteúdo da branch remota para o seu workspace. Clique com o botão direito sobre o projeto e selecione a opção: TortoiseGIT / Pull, conforme a imagem abaixo.

Ao executar o PULL, poderá ocorrer pontos de conflito no código, ou seja, classes que você alterou e que também foram alteradas na branch remota. Para verificar essas mudanças e comparar com as alterações locais, clique com o botão direito no projeto e vá em DIFF (Passo 1). Serão listados os arquivos em conflito (Passo 2). Com um duplo-clique na linha correspondente, é possível verificar as linhas na classe em conflito (Passo 3 ). Os ajustes podem ser realizados utilizando a opção User "theirs" text block onde é possível escolher o que será mantido ou retirado durante o merge (Passos 4 e 5).

Passo 1 - Visualizar as classes com conflito

Passo 2 - Listar as classes com conflito no projeto

Passo 3 - Realizar merge entre as classes remota e local

Passo 4 - Opções para resolver os conflitos entre as classes

Passo 5 - Marcar o merge como resolvido

COMMIT

Procedimento utilizado para marcar localmente o que deverá ser considerado como código alterado e passível de versionamento. Tanto para ajustes quanto para novas classes no projeto. É um estado anterior ao envio das classes, de fato, para a branch. Confira o procedimento na imagem abaixo.

PUSH

Procedimento utilizado para enviar a alteração para a branch remota.

Material Complementar

1. Pro Git book, Scott Chacon e Ben Straub, 2014.
2. Git - Guia prático, Roger Dudler, 2015.
3. Git version control with Eclipse, Lars Vogel, 2016.