Operações básicas com Git

Last modified by Wesley Silva on 2015/09/29 18:57

Operações Básicas com o Git

 

O que é o Git?

    O Git é uma ferramenta de controle de versões, um sistema que registra alterações em arquivos utilizados por vários usuários e guarda "fotografias" dessas mudanças. Sendo assim, com o Git é possível restaurar versões antigas de rotinas e anotações e evitar perdas de trabalho. Funciona com scripts de programação e arquivos txt (blocos de notas). Definições mais detalhadas podem ser encontradas no portal do Git.

    O software em questão é originalmente operacionalizado via linhas de comando. Entretanto, há várias implementações de interface gráfica que facilitam muito o seu uso. Um dos mais utilizados é o Git Extensions e será a plataforma utilizada na CGMA.

Funcionamento básico

 

    As operações do Git são realizadas em repositórios, diretórios locais ou online onde os arquivos e seu histórico de alterações são armazenados. A Figura 1 ilustra os tipos de repositórios e a relação entre eles.

ScreenClip [14].png

Figura 1: relação entre repositórios Git

    O repositório central é um diretório de distribuição, de onde os usuários irão obter as versões mais atuais dos arquivos. Já os repositórios locais são os repositórios de trabalho, localizados na máquina de cada usuário.

    Para entender o funcionamento, suponha que você queira trabalhar com um arquivo no seu repositório local. Antes de tudo, é importante obter do repositório central a versão mais atual desses arquivos. Com o click de alguns botões, o sistema faz essa busca no repositório central (setas azuis), com todo o histórico de alterações executadas anteriormente pelo resto da equipe, e armazena no seu repositório local. Chamamos essa operação de pull.

    Uma vez que você tenha feito alterações no arquivo, o Git extensions detecta essas alterações e avisa ao usuário e pede um comentário descrevendo o que foi alterado. O comentário sobre as alterações é chamada de commit.

    Nessa etapa, suas alterações estão comentadas e registradas, mas essa "fotografia" e a sua nova versão do arquivo ainda estão apenas na sua máquina local. Novamente com o click de alguns botões, o programa envia a nova versão ao repositório central (setas verdes), operação esta que é denominada push. Assim, quando outros usuários realizarem cada um um novo pull no seu repositório local, as alterações por você feitas por você e os arquivos alterados serão aplicadas nos diretórios locais destes. O histórico dessas alterações e as diferenças entre a versão antiga e a versão alterada podem ser visualizados dentro do Git Extensions.

Clonando um repositório central

               

    Antes de obter e compartilhar as versões e histórico de alterações, é necessário clonar um repositório central para uma pasta local. Esse procedimento é executado apenas uma vez para um dado repositório central. O Git literalmente clona tudo o que existe neste repositório para uma pasta, criando um repositório local. As figuras a seguir ilustram como executar essse processo no contexto da CGMA.

ScreenClip [13].png

Figura 2: selecionar a opção "Clone Repository"

ScreenClip [12].png

Figura 3: Localizar o repositório central em \\MISRV54\CGMA-DADOS\BASES_NOVO_ODR\

ScreenClip [11].png

Figura 4: Selecionar uma pasta na sua máquina local para clonar o repositório

Obtendo versão atual do repositório central: operação pull

 

    Uma vez que um repositório central é clonado, esse procedimento não precisa ser repetido. Automaticamente, o Git já insere no repositório local os arquivos e o histórico de versões e alterações disponíveis até o momento. De agora em diante, sempre que uma versão nova estiver disponível no repositório central, a atualização para o diretório local será realizada executando-se uma operação de pull, ilustrado nas figuras a seguir.

 

ScreenClip [10].png

Figura 5: Abrindo o repositório local (em nova sessão do Git)

 

ScreenClip [9].png

Figura 6: Iniciando um "pull"

ScreenClip [8].png

Figura 7: finalizando o "pull"

Documentando alterações: commit e stage

 

    Quando você altera os arquivos armazenados no repositório local e salva as alterações do arquivo, o Git detecta essas alterações e sinaliza no botão “Commit”, que se torna vermelho. Tal alerta serve para lembrar o usuário de que sua alteração deve ser validada e comentada. O commit executa essa etapa de validação e comentário.

ScreenClip [6].png

Figura 8: Rotina original, sem alteração

ScreenClip [5].png

Figura 9: Inserção de novas linhas no script e detecção de alteração no Git

    É necessário clicar no botão “commit” para que as alterações sejam validadas e comentadas. Ao clicar no botão commit, uma janela é aberta para descrição das alterações.

ScreenClip [4].png

Figura 10: janela de commit

 

    O primeiro quadro dessa janela mostra os arquivos editados (com um ícone de lápis ao lado), adicionados (nesse caso, aparecem com um sinal de "+") ou excluídos (sinal de "-"). Quando você clica  em um arquivo editado, o segundo mostra exatamente quais linhas dos arquivos foram alteradas comparando a versão antiga (em vermelho) com a versão nova (em verde).

    O botão "stage" serve para escolher os arquivos depois serão enviados ao repositório central (selecine um arquivo no primeiro quadro, clique em "stage", e esse arquivo será enviado ao repositório central no próximo push). O quadro inferior à esquerda lista os arquivos escolhidos.

    O botão "commit" irá armazenar localmente as o histórico das alterações. Entretanto, o sistema não permite que o commit seja feito sem que haja um comentário na área de "commit". Basta fazer um comentário breve sobre quais arquivos foram alterados e quais foram as alterações. 

    É possível desfazer as alterações com os botões reset changes. Um exemplo prático é quando você alterou algum arquivo, salvou as alterações no próprio programa (no R ou no bloco de notas, por exemplo) mas não pretende mandar para o repositório central. Nesse caso, o Git detectou essas alterações solicitou o commit. Mesmo com as alterações já salvas, o botão "reset changes" retorna os arquivos alterados para a versão original.

Compartilhando alterações: push

 

    Como foi dito anteriormente, o commit não envia as alterações ao repositório central. Assim, por enquanto nenhum membro da equipe tem acesso à sua nova versão. Para que todos tenham acesso às suas atualizações, é necessário fazer um push.

ScreenClip [3].png

Figura 11: remificações após o commit

    Para que as alterações “commitadas” sejam enviadas ao repositório central (e, portanto, estejam disponibilizadas ao restante da equipe), é necessário realizar um push das alterações.

ScreenClip [2].png

Figura 12: botão de início do push

 

ScreenClip.png

Figura 13: Finalizando o push

 

Comentários finais

    Vale salientar que o Git não muda a forma de trabalhar com scripts ou blocos de notas. Todo o trabalho de criação e edição de arquivos será feito no software desenvolvido para isso (trabalhos no R serão feitos no R, trabalhos em bloco de notas serão feitos em bloco de notas, etc.). O Git é apenas uma ferramenta auxiliar que detecta, grava e compartilha as alterações nesses arquivos. De toda forma, espera-se que essa ferramenta incremente tanto a agilidade quanto a integridade dos trabalhos executados pela CGMA.

Tags:
Created by Wesley Silva on 2015/02/24 15:42
    
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 6.3 - Documentation