3 METODOLOGIA DE PESQUISA
4.1 APLICAÇÃO DO SUBVERSION
4.2.2 Operações com o Git
São abordadas as operações que o git implementa e disponibiliza para o usuário, como possui muitas recursos, apenas os mais importantes são mostrados neste tutorial.
4.2.2.1 - Inicialização de Repositório
A criação do repositório é simples, basta navegar para o caminho ou pasta onde se deseja criar o repositório e digitar o comando da figura 53. Automaticamente é criado o branch
principal que por padrão é chamado master.
Figura 53 - Criar um Repositório Git
78 No caso apresentado foi gerado em uma pasta já existente e vazia, então o comando de inicialização do repositório apenas criou o diretório “.git”, conforme a figura 54:
Figura 54 - Conteúdo no Repositório no Git 1
Fonte: elaborado pelo próprio autor (2016)
Segundo Akita(2010), diferente do SVN e de alguns outros sistemas de controle de versão, ele não cria arquivos de metadados em cada sub-diretório, o git cria apenas um diretório, o “.git”, que além de representar todos os metadados do projeto ele contém o diretório com todos os dados, o histórico e as versões do projeto, isso é um facilitador, pois para fazer uma cópia de segurança do repositório só é preciso copiar o diretório “.git”.
Para efetuar a criação de um cópia de trabalho, no caso do Git uma cópia do repositório inteiro, é preciso efetuar um clone. A figura 55 mostra o comando utilizado para criar um clone
a partir de um repositório remoto contido no Github.
Figura 55 - Criação de Clone de Repositório Git 1
Fonte: elaborado pelo próprio autor (2016)
Na figura 55 é possível ver o comando para criar um clone, esse comando faz uma cópia local do repositório com todo o conteúdo, além do histórico de commits, tags, branchs. e demais metadados.
O git é auto-documentado, então para saber mais a respeito de algum de seus comandos é só utilizar o recurso help conforme é visto na figura 56.
79
. Fonte: elaborado pelo próprio autor (2016)
Como mostra a figura 56 o comando completo é o comando “git help” seguido do nome da funcionalidade.
4.2.2.2 - Commit, Stage, working directory e status
Apenas para um breve entendimento, segundo AQUITA(2010) o git possui a area de stage ou índice, o working directory e a operação commit. O working directory, como o próprio nome diz, é o diretório de trabalho, é o local onde se realiza alterações e se cria novos arquivos em tempo real. Em relação a área de índice AQUITA(2010) nos diz que essa área é invisível para o usuário, diferente do working directory ela não pode ser visualizada fisicamente no sistema de arquivo, seria como um um local temporário onde são acumulados os arquivos e as modificações antes de efetivamente serem enviadas em um commit. O commit é a operação que envia todos os arquivos e modificações na área de índice , para de fato serem armazenados no repositório.
Dentre as operações entre essas áreas, os arquivos podem ter 4 status, podendo um arquivo estar em mais de um status ao mesmo tempo, conforme mostra a figura 57.
80
Fonte: Chacon (2014)
Os status mostrados na figura 57 são:
● Untracked files,: são arquivos adicionados que não se encontram no último snapshot(commit), ou que foram renomeados ou deletados e se encontra-se puramente no working directory
● staged ou selecionado: são arquivos novos, ou alterados no working directory que foram adicionados na área de índice.
● modified: são arquivos que estavam no último snapshot, mas foram alterados. ● unmodified: são arquivos que , se encontram no working directory e também
no último snapshot , mas não tiveram nenhuma alteração.
Como pode ser visualizado na figura 58 o clone efetuado anteriormente trouxe para o disco local um projeto estruturado no padrão Mavem, o qual é explicado no apêndice A.
81
Fonte: elaborado pelo próprio autor (2016)
Os arquivos mostrados na figura 58 fazem parte do working directory, são neles que são feitas as edições e adições de arquivos e representam o snapshot mais atual do desenvolvimento Akita(2010). Para averiguar se esse working directory está sincronizado e igual ao repositório é preciso rodar o comando para verificar status apresentado na figura 59:
Figura 59 - Comando Status no Git 1
Fonte: elaborado pelo próprio autor (2016)
O comando “git status”, como o próprio nome diz, informa o status atual do branch local em relação ao branch remoto de origem, que é o “origin/master”, ainda informa se existe alguma alteração para ser submetida em commit.
Para uma elucidação mais prática da área intermediária ao commit e o diretório de trabalho, que é a área de índice, foi adicionado um arquivo no diretório, a criação do novo arquivo pode ser vista na figura 60.
Figura 60 - Adição do arquivo “Principal.java” no Git
Fonte: elaborado pelo próprio autor (2016)
Ao verificar o status em relação ao repositório remoto, o sistema informou que está tudo atualizado e que existe um arquivo que não está sendo versionado,na figura 61 pode ser visto o retorno.
82
Figura 61 - Comando Status no Git 2
Fonte: elaborado pelo próprio autor (2016)
O arquivo foi listado com o status Untracked file, como a própria expressão já diz, ele é um arquivo não rastreado, ele não estava no último commit e nesse momento ele se encontra apenas no working directory. Para adicioná-lo na área de stage e consequentemente iniciar o versionamento é necessário a seguinte instrução, conforme a figura 62.
Figura 62 - Adição de Arquivos no Git 1
Fonte: elaborado pelo próprio autor (2016)
Como mostra a figura 63 o status foi verificado novamente. Nota-se que agora o Git já mostra uma outra mensagem em respeito ao arquivo “Principal.java”, informando que as mudanças estão prontas para serem commitadas e que existe um novo arquivo.
Figura 63 - Comando Status no Git 3
Fonte: elaborado pelo próprio autor (2016)
Agora o arquivo “Principal.java” que ainda se encontrava vazio foi editado e o conteúdo
83 Figura 64 - Conteúdo do arquivo “Principal.java” no Git 2
Fonte: elaborado pelo próprio autor (2016)
O status foi verificado novamente, como mostra a figura 65. O arquivo agora está na área de índice com o status staged e na working area como modified, a área de índice possui apenas o arquivo vazio, enquanto o working directory possui as novas linhas escritas, como informado acima o working directory armazena o status mais atual do servidor. Entende-se então que um mesmo arquivo pode assumir vários status ao mesmo tempo.
Figura 65 - Comando Status no Git 4
Fonte: elaborado pelo próprio autor (2016)
Agora foram acrescentadas as modificações realizadas no arquivo “Principal.java” para a área de indice, conforme figura 66.
Figura 66 - Adição de Arquivos no Git 2
Fonte: elaborado pelo próprio autor (2016)
Uma observação a ser feita é que após o comando foi utilizado o sinal “*” e não o nome do arquivo, esse modo que foi aplicado ao comando pega todos os arquivos do working directory e os envia para área de índice, é possível usar também expressões regulares, como por exemplo “git add *.java”, nesse exemplo ele envia para a stage area todos os arquivos com a extensão “.java”.
84 Novamente o status foi verificado e como é visto na figura 67 no retorno do comando, é mostrado apenas o novo arquivo pronto para ser enviado.
Figura 67 - Comando Status no Git 5
Fonte: elaborado pelo próprio autor (2016)
Agora é a hora de submeter as alterações por meio de um commit. Por padrão o commit salva no repositório apenas os arquivos que estão na área de índice, mas é possível também enviar alterações que ainda estão apenas no working diretory. A realização do commit é mostrada na figura 68. O argumento “-m” é utilizado para adicionar uma mensagem que informa o motivo do commit, que neste caso foi a adição do arquivo “Principal.java”.
Figura 68 - Commit no Git 1
Fonte: elaborado pelo próprio autor (2016)
O comando git retorna o log dos commits, na figura 69 é possível visualizar o comando aplicado.
Figura 69 - Comando Log no Git 1
Fonte: elaborado pelo próprio autor (2016)
O argumento “-- graph” é para retornar o log de commit de forma gráfica e mais amigável, é possível visualizar o retorno na figura 70. Nota-se que no log aparece o último commit, que é mostrado na figura 68, com a mensagem informada, com o nome do autor do commit, data e hora. O commit é representado por um hash sha1, esse algoritmo pega todos os dados e arquivos desse commit, mais um cabeçalho e gera esse hash, se o usuário mudar apenas
85 um único caractere dentro do arquivo, ou até mesmo de alguma estrutura interna do controle de versão o hash se torna totalmente diferente, segundo Akita(2010) além de servir como identificador único, ele também fornece integridade aos dados. O sha1 possui aproximadamente 40 caracteres, então o risco de colisão, ou seja 2 commits com o mesmo hash são quase impossíveis.
Figura 70 - Árvore de Log no Git 1
Fonte: elaborado pelo próprio autor (2016)
Além do comando que retorna um log do commits, o Git fornece o “gitk”, que é um cliente nativo do git, que mostra o grafo de commits, branchs e remotos em uma interface gráfica. Para utilizar basta digitar o comando mostrado na figura 71 e em seguida como mostra a figura 72 abre-se a janela com todas as informações dos commits.
Figura 71 - Comando Gitk no Git 1
86 Na figura 72 é mostrada a janela do gitk, que por sinal é simples e traz apenas o que é necessário para se saber dos commits,
Figura 72 - Janela do Gitk no Git
Fonte: elaborado pelo próprio autor (2016)
4.2.2.3 Ignorar arquivos
Um projeto de software pode possuir vários arquivos de metadados, às vezes são arquivos deixados pelo gerenciador de build ou por uma IDE, esse arquivos são muito necessários para a construção e desenvolvimento do ambiente do desenvolvedor, mas não é necessário estar no repositório, para isso existe o arquivo “.gitignore”. Conforme mostra a figura 73 ele fica no mesmo nível de diretório que o arquivo “.git” se encontra. Neste arquivo são armazenadas as regras que o git considera para ignorar pastas e arquivos.
87
Fonte: elaborado pelo próprio autor (2016)
O conteúdo do arquivo pode ser visto na figura 74. De acordo com as regras já estabelecidas o arquivo “.classpath”, qualquer documento ou diretório dentro de “target”, dentro de “.settings/” ou .idea/* não são submetidos no “.git”, são ignorados pelos sistema.
Figura 74 - Conteúdo do arquivo “.gitignore” no Git 1
Fonte: elaborado pelo próprio autor (2016)
Para realização de teste foi acrescentada mais uma linha ao arquivo, como mostra a figura 75 a linha escrita estabelece que serão ignorados arquivos que tenham a extensão “teste”. Ainda é possível ver na figura 76 o status do arquivo “.gitignore” está marcado como modificado.
Figura 75- Conteúdo do arquivo “.gitignore” no Git 2
Fonte: elaborado pelo próprio autor (2016)
Na figura 76 é mostrado na última linha que se pode ver enquadrada na imagem, que o arquivo está modificado.
88
Figura 76- Comando Status no Git 6
Fonte: elaborado pelo próprio autor (2016)
Agora em continuação aos testes foi adicionado o arquivo “tcc.teste” conforme figura 77 e a listagem dos arquivos na figura 78. Em seguida na figura 79 o status mostra apenas que o arquivo “gitignore” está modificado, não mostra informação nenhuma a respeito do novo arquivo adicionado, o que mostra que a regra para ignorar foi aplicada corretamente.
Figura 77 - Adição de Arquivos no Git 3
Fonte: elaborado pelo próprio autor (2016)
Figura 78 - Listagem de Projeto Clonado no Git 3
Fonte: elaborado pelo próprio autor (2016)
Como se esperou, na figura 79 é possível visualizar que apenas a modificação realizada no arquivo “gitignore” é mostrada entre as alterações.
89 Figura 79 - Comando Status no Git 7
Fonte: elaborado pelo próprio autor (2016)
4.2.2.4 - Git Reflog
Nada no git é perdido, por mais que algum usuário exclua um commit, é possível recuperar os dados. O recurso base para isso é o comando “git reflog”. Para realizar um exemplo de teste, supões-se que o usuário deseja excluir o último commit, pois foram alterados os arquivos de forma errada e se deseja excluir todas as alterações. Até o momento a árvore de
commits é a seguinte mostrada na figura 80.
Figura 80 - Árvore de commit no Git 1
90 A exclusão da última submissão mostrada na figura 80 pode ser vista na figura 81.
Figura 81 - Exclusão de commit
Fonte: elaborado pelo próprio autor (2016)
A explicação do que foi utilizado na figura 81 é a seguinte: o comando “reset”, volta as alterações realizadas pelo commit; A declaração “HEAD^1” é uma referência ligada ao último commit do branch atual, praticamente falando o “HEAD^1 foi utilizado para o git voltar um commit; o parâmetro ”--hard” é para informar que o git deve descartar tudo que foi realizado no último commit, é possível enviar para a área de índice usado o parâmetro “--soft”, o que seria inclusive o mais recomendado; em relação ao retorno que o git mostra, o sistema informou que o último commit, o HEAD, agora é o commit com o hash começando em “7b436a2”, conforme a figura 82 mostra.
Figura 82 - Árvore de commit no Git 2
91 Anteriormente o commit começando por “b55ae1b” foi descartado, mas o git permite reverter, o que se torna interessante em caso de exclusão acidental.
Para realizar a reversão é necessário saber o hash do commit que se deseja restaurar, para saber basta utilizar o recurso “reflog”, para listar os commits que estão na “lixeira do git”. Figura 83 - Comando Git reflog 1
Fonte: elaborado pelo próprio autor (2016)
Na figura 83 pode ser visto o comando sendo utilizado, na figura 84 é mostrado a listagem do que já foi descartado,
Figura 84 - Retorno do comando reflog
Fonte: elaborado pelo próprio autor (2016)
Como visto na figura 84, o commit descartado que se deseja restaurar está no índice 2 que é marcado como 1, no qual o hash é o “b55ae1b”, para reverter o commit foi utilizado o recurso merge, que permite trazer as alterações. Na figura 85 é possível ver o comando merge sendo executado.
Figura 85- Comando merge no Git 1
Fonte: elaborado pelo próprio autor (2016)
Na figura 86 o log de commit foi novamente verificado e o commit restaurado já aparece na lista de commits realizados.
92
Figura 86 - Árvore de commit no Git 3
Fonte: elaborado pelo próprio autor (2016) 4.2.2.5 Stash
O git oferece um interessante recurso chamado stash, é uma pilha de modificações que o usuário pode manter no git e retornar para o working directory quando quiser. É uma forma de limpar o status do working directory e jogar tudo que está pendente ou inacabado em uma caixa de forma que fique em espera. O git permite colocar algo do stash de volta no working directory quando o usuário quiser.
Para exemplificar, supõe-se que está criando uma nova funcionalidade e para tal foi criado um novo arquivo chamado “Pessoa.java” como mostra a figura 87.
Figura 87 - Conteúdo do Arquivo Pessoa
Fonte: elaborado pelo próprio autor (2016)
Agora é necessário parar o desenvolvimento dessa classe Java, porque é preciso arrumar um bug em ambiente de produção urgente. O que fazer?
93 O usuário poderá efetuar um commit para limpar o working directory, mas as boas práticas de desenvolvimento não recomendam submeter algo que não está pronto ou que está pela metade. A figura 88 mostra o status atual do repositório com o arquivo “Pessoa.java” marcado como não versionado.
Figura 88 - Comando Status no Git 8
Fonte: elaborado pelos próprios autores (2016)
O arquivo “Pessoa.java” esta apenas no working directory e como ainda está marcado como não versionado é necessário antes que seja adicionado ao indíce através do comando “git add”, feito isso a figura 89 já mostra a o arquivo como um novo arquivo não submetido, enquanto que na figura 90 é mostrado o comando para enviar a alteração para a área de stash.
Figura 89 - Comando Status no Git 9
Fonte: elaborado pelos próprios autores (2016)
A figura 90 mostra a utilização do comando para enviar alterações do working directory para a área de stash.
94
Fonte: elaborado pelos próprios autores (2016)
Na verificação do status realizada na figura 91, como esperado não é apresentado nenhuma alteração.
Figura 91- Comando Status no Git 10
Fonte: elaborado pelos próprios autores (2016)
O arquivo agora está na área de stash, é possível listar o que está incluído na área de stash através do comando mostrado na figura 92 e teve como resultado o que é mostrado na figura 93.
Figura 92 - Comando de listagem do stash
Fonte: elaborado pelos próprios autores (2016)
Na figura 93 é mostrada a listagem do conteúdo que está contido na área de stash.
Figura 93 - Retorno de listagem do stash
Fonte: elaborado pelos próprios autores (2016)
Como dito anteriormente o Git ainda permite recolocar o que está no stash no work directory. Figura 94 - Comando stash apply 1
95
Fonte: elaborado pelos próprios autores (2016)
O comando “git stash apply” mostrado na figura 94 traz o último stash salvo, para trazer um stash em específico o comando é “git stash apply <stash> “ conforme figura 95. O stash tem variantes que podem ser consultadas através do comando “git help stash”.
Figura 95 - Comando stash apply 2
Fonte: elaborado pelos próprios autores (2016)
4.2.2.6 - Branch
A definição de branch ou ramo pode ser encontrada no capítulo 2, o git tem como seu ponto forte o uso de branchs, isso foi uma das premissas da criação do git, podendo trabalhar nas mais variadas formas. Em relação ao fluxo de branches foi criado o gitflow , que é um modelo para gerenciamento de branches no git, para saber mais sobre isso consulte o Apêndice B. Nesta seção são abordados os branchs. Primeiro o ramo mais importante do git é o master, que por convenção costuma ser o que possui o código existente em produção, então todas as alterações têm como ponto final o master.
Primeiramente para listar todos os branchs existentes no repositório é necessário utilizar
o seguinte comando mostrado na figura 96.
96
Fonte: elaborado pelos próprios autores (2016)
Na figura 96 foi listado apenas o branch master no repositório, por conter o código de produção não é recomendável criar novas funcionalidades diretamente nele, em respeito para com as boas práticas e para fins de teste, foi criado um novo branch chamado
“desenvolvimento”, conforme figura 97 e 98.
Figura 97 - Criação de branch no git 1
Fonte: elaborado pelos próprios autores (2016)
Na figura 98 é possível ver o novo branch criado listado com os demais branches. No caso do git na criação do branch o sistema já alterna para o novo branch.
Figura 98 - Listagem de branchs no git 2
Fonte: elaborado pelos próprios autores (2016)
O comando checkout faz uma cópia do branch em que se está e coloca todos os dados copiados no novo branch, assim como também marca automaticamente o novo branch.
Para retornar para o branch master basta seguir o mostrado na figura 99.
Figura 99 - Checkout branch master no git 1
97
Por mais que o novo branch seja uma cópia do master, tudo que é feito nele não tem impacto sobre o sua cópia, fornecendo forte segurança para o desenvolvedor. Para exemplificar foi deletado o último commit do branch master. Na figura 100 é mostrado o log de commit antes da exclusão na figura 101 é realizado o comando de exclusão e na figura 102 é listado novamente o log onde não aparece mais o commit excluído. Figura 100 -Log de commit no git 1
Fonte: elaborado pelos próprios autores (2016)
Na figura 101 é realizado o comando para excluir o último commit realizado.
Figura 101 - Exclusão do último commit
Fonte: elaborado pelos próprios autores (2016)
Na figura 102 é possível ver que o penúltimo commit realizado passou a ser o primeiro, o head do repositório.
98
Figura 102 -Log de commit no git 2
Fonte: elaborado pelos próprios autores (2016)
Agora para teste é necessário voltar para o branch desenvolvimento para conferir como está o log de commit. Na figura 103 é realizado o retorno ao branch desenvolvimento e na figura 104 é visualizado o log que ainda mostra o commit com hash iniciando em “718b35”.
Figura 103 - Checkout branch desenvolvimento
Fonte: elaborado pelos próprios autores (2016)
Como esperado, o branch desenvolvimento não foi afetado, na figura 104 é mostrado que o commit excluído no branch master ainda existe em desenvolvimento.
Figura 104 - log do branch desenvolvimento
99 4.2.2.7 - Merge e Rebase