Por Alex Coqueiro e Eduardo Rocha

---

 

O serviço de CodeCommit provê um ambiente para o gerenciamento de códigos-fonte e artefatos de deployment escalável e autogerenciado. Esse serviço é compatível com os comandos de Git, e o objetivo deste artigo é mostrar como interagir com esse serviço por meio de exemplos com os cenários mais comuns no uso de gerenciamento de código distribuído.

Para iniciar, mostraremos como criar um novo repositório no CodeCommit.

Vamos criar o seu repositório na AWS CodeCommit: Escolha a opção “CodeCommit” na sua console:

Se você não tiver repositório algum, essa página abaixo irá aparecer para você, então clique em “Get Started”. Apenas como lembrete, o CodeCommit só funciona na região Virgínia, então não se esqueça de mudar a sua região, senão você não conseguirá criar o repositório.

Depois de você clicar lá, você precisa criar o seu novo repositório. Escolha um nome e uma descrição – aqui nós criamos uma apenas de exemplo:

Perfeito! Agora você está apto a ver a sua dashboard, na qual é possível visualizar todos os seus repositórios ativos e uma opção para a criação de novos repositórios.

Vamos escolher o nosso repositório de exemplo:

Ao clicar, você terá uma visão geral do seu repositório. Com a nova atualização, o CodeCommit está com uma interface nova. Aqui temos os detalhes do repositório:

Como podemos ver, em cima de “Settings” temos a opção “Code”, na qual o CodeCommit permite navegação dentro do repositório e visualização dos arquivos e códigos:

Nessa seção, é possível ver os arquivos contidos no repositório (iremos colocar esse arquivo no repositório nos próximos tópicos deste artigo), como pegar a URL HTTPS e SSH. Também é possível efetuar a troca de branch (veremos mais tarde também). Ao clicar em cada item, é possível ver o seu código na interface do CodeCommit:

Perfeito! Agora você tem um repositório CodeCommit ativo na sua conta AWS.

Conforme dito anteriormente, a interação com o CodeCommit é feita via comandos Git. Dessa forma, acreditamos que os passos a seguir serão muito úteis para profissionais que tenham pouca experiência com o Git. Caso essa não seja a sua situação, possivelmente você pode pular esta seção.

Primeiro vá a esta URL e faça a instalação do Git no seu computador, para Windows, Mac OS, Solaris e Linux: https://git-scm.com/downloads

Neste artigo, vamos começar com alguns comandos básicos do Git no nosso prompt do Windows, mas você pode usar o GIT Bash, que é um prompt próprio do Git que está incluído na sua instalação.

Na pasta “Example” (que está vazia), no meu disco “C:”, colocamos um código PHP como exemplo, mas isso pode ser feito com qualquer arquivo/código em qualquer linguagem/extensão, por exemplo:

Você pode colocar o arquivo “info.php” na sua pasta manualmente, como fizemos na nossa.

Mas e se você tiver arquivos que não queira que o Git visualize? Simples, é só criar um arquivo chamado “.gitignore” (sim, desse jeito) e dentro dele escrever o nome dos arquivos que você não deseja que o Git visualize e, então, esses arquivos não serão vistos, eles serão ignorados.

Antes de começar com os comandos, é importante saber um item essencial com relação à estrutura do Git. Esse sistema de controle de versão trabalha com áreas, que são divididas em três: working area, staging area e repositório Git.

A working area é a sua área de trabalho, onde você modifica seus arquivos à vontade, sem que sejam trackeados (controlados) pelo Git. Seus arquivos estão na staging area depois que você executa um código de adição e aí, sim, eles começam a ser trackeados pelo Git. E, por fim, estão no repositório Git, quando você executa um comando de commit neles (veremos mais abaixo) e então a versão passa a ser guardada no seu Git.

1. Configurando o seu Git

O Git possui estruturas de variáveis de ambiente que podem ser configuradas e servirão para controlar as alterações feitas por autor e data da alteração, por isso essa configuração é tão importante. Para ver as configurações atuais, você pode preencher o comando “git config –list”. A alteração das variáveis de ambiente podem ser feita de forma dinâmica por meio dos comandos “git config –global user.name <seu nome>” e “git config –global user.email<seu email>”.

 

2. Criando o repositório Git

Para isso, vá à sua pasta (usando os comandos de prompt “cd nome da pasta/caminho”) e digite o comando “git init”:

3. Checando status e adicionando arquivos para o seu repositório Git

Aqui você pode ver o status da sua pasta Git usando o comando “git status”.

O nome do seu arquivo em vermelho mostra que o arquivo ainda não foi adicionado. Para fazer isso, use o comando “git add <arquivo1> <arquivo n>” para adicionar apenas alguns ou um arquivo específico na staging area, ou “git add –a”/ “git add –A/ “git add .” para adicionar todos os arquivos. E foi isso que fizemos:

Você também pode adicionar todos os arquivos de um determinado formato, usando o comando “git add *.extensão do arquivo”.

E caso você tenha lembrado que um arquivo específico não era pra ter sido adicionado à sua staging area, mas você adicionou todos os arquivos de uma só vez? Simples, use o comando “git reset HEAD <nome do arquivo>” para retirá-lo da sua staging area.

O nome do seu arquivo em verde mostra que seu(s) arquivo(s) está/estão pronto(s) para ser/serem comitados, mas o que é o commit?

4. Comentando seu arquivo/código

Aqui você comenta o seu código para a próxima pessoa que irá ver o seu arquivo/código alterado e o move para o repositório. Para isso, use o comando: “git commit –m <comentário>”. Caso você não use a diretiva “-m”, o Git irá te direcionar para o editor de texto vi (já que o Git foi desenvolvido baseado em Linux) para você inserir o seu commit e o que mais você quiser. A diretiva “-m” nos poupa esse trabalho.

Para desfazer algum commit em caso de você ter esquecido alguma coisa e queira incluir no mesmo commit, ou errou na digitação, é usado o comando “git commit –amend”.

Esse comando indica que você vai editar o seu commit mais recente e, para deixá-lo mais completo, use após a diretiva “–amend” a diretiva “-m “ ‘Mensagem nova’ ” da mesma forma que você fez antes. Ele completo fica assim: “git commit –amend –m <mensagem nova>”.

Também é possível adicionar o arquivo e dar o commit nele no mesmo comando; é só utilizar “git commit -a -m<Mensagem> “ e seu arquivo será movido da working area para o seu repositório no mesmo comando.

5. Criando uma pasta remota para o seu repositório AWS CodeCommit

Isso é muito simples! Você vai apenas criar uma pasta remota que vai representar a seu repositório AWS CodeCommit. Lembra daquela URL HTTPS da sua conta? Você vai precisar dela. Para isso: “git remote add <nome da pasta remota> < URL do seu repositório AWS CodeCommit >”.

6. Enviando (pushing) os códigos/arquivos para o seu repositório AWS CodeCommit

Pronto! Agora você pode enviar (push) tudo para o seu repositório AWS CodeCommit. Para isso, você vai usar o comando: “git push <Nome da pasta remota> <nome do branch>. Mas pera aí… Branch? Você pode criar um novo branch (o que não é necessário agora) e colocar seu nome, mas já que nós não fizemos isso, vamos usar o branch padrão, que é: “master”.

Esse caso acontece quando você dá o seu primeiro push no repositório. Quando não é o primeiro, você precisa atualizar o seu repositório com o comando “git pull”, do qual falaremos mais abaixo, no item 15.

7. Clonando o repositório AWS CodeCommit para o seu computador

Agora você tem todos seus arquivos no seu repositório AWS CodeCommit, e vamos imaginar que outra pessoa quer ver esse código/arquivo. Para esse exemplo, eu fiz outra pasta no meu C: para mostrar pra vocês (mkdir Example2, cd Example2). Para isso, use o comando: “git clone <URL do seu repositório AWS CodeCommit >”.

8. Confirmando a existência do arquivo

Aqui é apenas para confirmar se o arquivo está lá, com comandos no prompt:

Em “C:/Example2”, eu usamos o comando “dir” para mostrar todas as pastas que estão lá; usamos “cd MeusPrimeirosCodigos” (nome do seu repositório CodeCommit) e o “dir” novamente, e nosso arquivo “info.php” estava lá :D.

9. Comparação entre diferenças de versões anteriores

O Git te mostra após o comando “git status” o que foi feito no seu projeto – se arquivos foram adicionados, modificados ou removidos. Falaremos neste tópico apenas das alterações.

Para verificar alterações, usaremos o comando “git diff” e suas variações. Esse comando pega as diferenças entre versões que estão na sua working area e as diferenças entre versões da sua staging area.

Quando o arquivo está na working area, ou seja, ANTES do “git add” e você quer verificar o que foi alterado, é só utilizar o comando “git diff” e irão aparecer para você todas as alterações que foram feitas no(s) seu(s) arquivo(s) enquanto estão na working area.

Quando você transferir o(s) arquivo(s) para a staged area e quiser ver o que foi alterado, é só acrescentar uma diretiva ao comando anterior, e ele ficará “git diff –staged”. Então, você será capaz de visualizar as alterações feitas no(s) arquivo(s) com ele estando na staged area.

10. Verificando alterações e registros após o commit

Um comando muito útil para ver as pessoas que alteraram os arquivos é o git log. Ele mostra todos os commits executados, o autor (que é dado na configuração do item 2 acima), a data, o conteúdo desse commit e uma chave que identifica o seu commit. Porém, é possível alterar a visualização desse log com diretivas que podem dar menos ou mais detalhes, como estas:

• “git log -(número)” = Mostra a quantidade de logs que você deseja ver, sempre começando do mais recente.
• “git log –format=fuller” = Mostra informações a mais com relação ao git log sem a diretiva, um registro mais completo.
• “git log -g” = Mostra informações referente ao HEAD do commit (falaremos de HEAD mais abaixo), o que possibilita ver, por exemplo, em qual versão foi feita a alteração.
• “git reflog” = Mostra todas as referencias de mudança no seu respectivo repositório de trabalho.
• “git log –stat” = Mostra informações sobre os arquivos que foram alterados.
• “git log –pretty=oneline” = Mostra apenas o código do commit e a mensagem sem mostrar os detalhes de data, hora e autor.
• “git blame <arquivo>” = Mostra o conteúdo do arquivo específico.

11. Desfazendo mudanças da working area mesmo após um commit

Toda vez que você commita um arquivo e o modifica determinado tempo depois, o Git aponta que esse arquivo foi alterado ou que novos arquivos foram incluídos no projeto. Após você checar o seu status e para ser atualizado no diretório, você precisa refazer o fluxo de mover da working para staging area e dela para o repositório. Mas agora vamos pensar em uma situação: um arquivo é modificado, e depois o autor se lembra de que determinada alteração não deveria estar lá, como resolver? Usando o comando “git checkout — <nome do arquivo>”. Esse comando vai retornar o arquivo para o jeito que ele estava antes de essas alterações acontecerem, ou seja, do último commit dado. Só lembrando que só será aplicável se o arquivo estiver na working area; após ele ter passado para a staging area, o comando é outro (retorne aos itens 3 e 4).

12. Excluindo arquivos da working area

Esse caso é bastante específico. Ele acontece quando você faz uma série de modificações nos arquivos da sua working area, e você executa uma remoção de arquivos que já foram comitados anteriormente. Ao fazer uma adição (git add .), o Git irá informar que existem arquivos que não existem mais no seu projeto e que precisam ser deletados antes de você realizar o commit (como foi explicado no item 9). Como fazer isso? Da mesma forma que o Git tem um comando para adicionar arquivos, ele tem um para remover, e esse comando é o “git rm <nome do arquivo>”. Pronto, após esse comando ser dado, você consegue realizar o commit com os arquivos corretos e sem nenhuma pendência.

13. Trabalhando com tags

Primeiramente, o que é uma tag? É uma etiqueta, serve para identificar versões do seu sistema. Aqui está uma lista de comandos relacionados a tags, todos diferenciados por diretivas, mas a base deles é “git tag”.

• “git tag” = Lista todas as tags existentes no seu sistema.
• “git tag -a<valor da tag> -m<comentário>” = Cria uma tag na diretiva de valor e identifica a que se refere à tag na diretiva comentário. Com a diretiva -a, a sua tag é salva com especificações de autor da tag e data de gravação, sendo mais poderosa no sentido de controle.
• A tag é criada sempre para o seu commit atual, mas também é possível criar para commits anteriores:
• “git tag -a<valor da tag> <chave do commit> -m<comentário> ” = A chave do commit, nesse caso, é aquela obtida com o comando “git log”.
• “git show <nome da tag>” = Mostra tudo com relação a essa tag, o autor, data e os dados do commit que foram relacionados a essa tag, caso exista.
• “git checkout <nome da tag> ” = Mostra os arquivos pertencentes a essa tag (versão). Ao utilizar esse comando checkout, você estará no ambiente dessa tag, tendo acesso aos arquivos pertencentes apenas a essa tag. Lembrando que deve-se usar esse comando após vincular uma tag a um commit, e assim estaremos usando corretamente uma tag para o controle de versão.
• “git tag –d <nome da tag> ” = Deleta uma tag, só lembrando que você deleta a IDENTIFICAÇÃO, e não os ARQUIVOS que estão no commit. Apenas reforçando que a tag é semelhante a uma etiqueta.

14. Trabalhando com branches

Um branch é uma ramificação do sistema de controle de versão. O Git tem como padrão o branch chamado “master”, mas você pode e deve criar outros branches para controlar as suas versões de forma mais adequada. É extremamente poderoso ao ser utilizado para realizar testes e para criar ambientes de desenvolvimento sem que existam interferências e evitando problemas de perda de arquivos. O nome do branch que você está trabalhando sempre estará entre parênteses no final do caminho da sua pasta, caso esteja usando o Git Bash. Aqui está uma lista de comandos relacionados a branches:

• “git branch <nome do branch>” = Cria um novo branch.“git checkout <nome do branch>” = Troca para o novo branch.
• “git checkout -b <nome do branch>” = Cria um novo branch e troca para ele, junção dos dois comandos anteriores.
• “git merge <nome do branch>” = Junta as alterações de um branch para outro. Lembrando que, nesse caso, você deve estar no branch em que deseja atualizar as informações. Exemplo: PastaExemplo/PastaProjeto (master) $git merge branchTeste.
• “git branch –d <nome do teste>” = Deleta um branch.
• “git branch –m <nome atual do branch> <novo nome do branch>” = Renomeia o branch.
• “git ls-files” = Lista os arquivos de um branch.

15. Atualizando (pulling e fetching) repositórios remotos

O pull é um comando para você atualizar o seu repositório remoto e depois dar o push nos seus arquivos (caso não se lembre do push, volte ao item 6). Ele sincroniza os seus arquivos da máquina local com o servidor remoto (item 5) para usar o push e subir os arquivos no seu repositório AWS CodeCommit da forma mais adequada e atualizada.

O comando é: “git pull <nome do repositório remoto> <nome do seu branch>”. Após esse comando, o seu repositório remoto estará atualizado e pronto para o push.

O pull é um comando poderoso, mas que possui uma pequena peculiaridade que pode acabar te atrapalhando: ao executar esse comando, o Git faz um merge (junção) do seu workstation (branch) com o repositório remoto, e isso pode não ser interessante.

Quando não é desejado fazer isso, o comando escolhido é o “git fetch <nome do repositório remoto> <nome do branch>”. Nesse caso, é interessante você executar esse comando em um branch dedicado para isso. Mas, na maioria das vezes, o pull atende bem às necessidades.

Neste artigo, focamos nos comandos de git. Importante salientar que você pode utilizar ferramentas gráficas que reconhecem os comandos Git. Um desses exemplos é o Atlasian SourceTree (leia o artigo Atlasian [sourcetree com codecommit]: http://grimpanda.com/amazon-codecommit-and-sourcetree-setup-tutorial-with-ssh-keys/ e configure o Source Tree.

Ótimo!! Agora você pode versionar/compartilhar seus códigos entre as suas equipes de trabalho utilizando o AWS CodeCommit!

Links úteis

• • Aprendendo mais comandos Git
  • Mais sobre o CodeCommit: http://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html
  • Mais sobre comandos Git e ambientes: https://www.youtube.com/watch?v=WVLhm1AMeYE&list=PLInBAd9OZCzzHBJjLFZzRl6DgUmOeG3H0