- Wiki Home: Projeto ODR UnB/MI
- 1. Arquitetura e ambiente do servidor para soluções georreferenciadas (com foco no ODR)
- Operações básicas com Git
Operações básicas com Git
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.
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.
Figura 2: selecionar a opção "Clone Repository"
Figura 3: Localizar o repositório central em \\MISRV54\CGMA-DADOS\BASES_NOVO_ODR\
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.
Figura 5: Abrindo o repositório local (em nova sessão do Git)
Figura 6: Iniciando um "pull"
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.
Figura 8: Rotina original, sem alteração
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.
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.
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.
Figura 12: botão de início do push
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.