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

[[Ambiente Desenvolvedor|'''Voltar''']]
<br/><br/>
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.

[[Arquivo:Git-estrutura-branch.png]]

==Regras diárias do fluxo de versionamento a ser seguido pela equipe==
A ferramenta visual escolhida para utilização do GIT foi o TortoiseGIT. 
# Fazer o '''pull''' no início do dia, antes de cada '''commit''' e/ou quando julgar necessário.;
# 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.

[[Arquivo:Git-pull.png]]

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====
[[Arquivo:Git-diff.png|Visualizando as classes com conflito]]

====Passo 2 - Listar as classes com conflito no projeto====
[[Arquivo:Git-view-diff.png|Lista de classe com conflito no projeto]]

====Passo 3 - Realizar merge entre as classes remota e local====
[[Arquivo:Git-merge-diff1.png|Merge entre as classes remota e local]]

====Passo 4 - Opções para resolver os conflitos entre as classes====
[[Arquivo:Git-merge-diff-conflit.png|Opções para resolver os conflitos entre as classes]]

====Passo 5 - Marcar o merge como resolvido====
[[Arquivo:Git-merge-diff-mark-solved1.png|Marcando 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.

[[Arquivo:Git-commit.png]]

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

[[Arquivo:Git-push.png]]

== Material Complementar ==
# [https://git-scm.com/book/pt-br/v1 Pro Git book], Scott Chacon e Ben Straub, 2014.
# [http://rogerdudler.github.io/git-guide/index.pt_BR.html Git - Guia prático], Roger Dudler, 2015.
# [http://www.vogella.com/tutorials/EclipseGit/article.html Git version control with Eclipse], Lars Vogel, 2016.