logo

Dicas de GIT para Testers

Seguindo a ideia de fazer posts com alguns conceitos básicos e informações úteis no dia-a-dia, outro item que deixa alguns testers apavorados é com repositório GIT.

Não é para menos, o amigão eh meio complexo, não tem interface gráfica por default e muitos comandos e conceitos para você "decorar".
Eu já vi marmanjo arquiteto de software chorar para fazer um merge, que dirá um tester começando a ficar mais técnico?

E mais cedo ou mais você terá que versionar seu código de automação e deus queria que você use o git, caso contrário vai sofrer com SVN ou similares, rs.

Admito que processos de merge ou diff de código são mais chatos e devem ser feitos por alguém com experiência, porém o dia a dia de uso do GIT é bem suave.

Só para não dizer que não falei das flores, GIT é um projeto open source de versionamento de código fonte.

Existe uma extensão para windows que tem uma telinha bonitosa, que torna as coisas menos dolorosas, mas sem saber os conceitos, a tela não vai te ajudar muito. check it out --> git extentions

Eu não vou entrar em detalhes de autenticação, por que depende do seu ambiente (github, gitorious,gitlab,etc) você pode autenticar com usuário e senha ou através de chave pública ssh.

Posso até extender o post mais tarde para adicionar essas informações mas por hora não.

TLD:DR caso vc queira ler o livro inteiro sobre git traduzido, acesse http://git-scm.com/book/pt-br. este post aborda o básico para profissionais de teste com pouca ou nenhuma base técnica.

O básico

Git é o core do repositório de arquivo correto? Pode existir servidores especificos como GITORIOUS ou o famoso GITHUB que são serviços que provem um repositório GIT por $$ ou favores...rs

Para interagir com um repositório GIT, existe alguns comandos básicos.

Antes de começar vc precisa dizer ao mundo git quem é você:

    $ git config --global user.name "Leonardo Galani"
    $ git config --global user.email leo@keeptesting.com.br

Cada push que você fizer no repositório, terá essas informações.


O comando clone baixa para sua máquina uma cópia do repositório escolhido, ou seja, não tem muito segredo.

git clone https://github.com/camiloribeiro/icecream.git

Caso você jah tenha um repositório na sua máquina e quer pegar a "última versão", o comando pull da conta do recado. Você vai perceber que não é necessário colocar o endereço do repositório novamente pois quando você baixa o repositório com o comando clone, ele cria um arquivo oculto com as informações do mesmo (isso também vale para o comando push):

git pull

Para ter o tracking de toda alteração que você faz no seu código, você precisa commitar seu código no repositório.

Isso é necessário para identificar o que você alterou e o que vem do repositório / branch. Caso você baixe uma nova versão do repositório no meio de um trabalho, seu arquivo commitado não será sobreescrito pela versão do repositório.

OBS: caso a versão no repositório seja mais recente do que a versão base que você alterou, o git vai reclamar de conflito de versão. Trataremos desse assunto em um próximo update do post. :)

Porém antes de comitar suas alterações / incluir novos arquivos, você precisa colocar esses arquivos no estado de stage que é um preparatório para seu commit

No caso de adicionar um novo arquivo ao repositório, é preciso acessar a pasta do arquivo e usar o seguinte comando

git add nome_do_arquivo

Bem simples né?

Agora para fazer o stage dos arquivos que você alterou, você pode usar o comando:

git add -i

Ele vai abrir uma "tela" no console mostrando os arquivos alterados e o que você quer fazer.

Caso você queira fazer stage de todos os arquivos na pasta e subpastas, você pode pular direto para o comando:

git add -p

Depois de colocar os arquivos em stage, é hora de fazer o commit com uma mensagem observação para saber o que foi alterado.

git commit -m "Adicionando Casos de teste XXX"

Cada commit no repositório é gerado um HASH, ou seja, caso seja necessário voltar para commits anteriores, é possivel utilizar esses hashs.

O parâmetro -m é que define a mensagem.


Depois de commitar as alterações é necessário mandar esse código para o repositório e assim será visível para os outros usuários que fizerem um pull do projeto usando o comando PUSH:

git push 

Digamos que você fez aquela besteira, criou arquivo que não precisava e que precisa remover do repositório.. basta usar o comando rm:

git rm nome_do_arquivo_a_ser_deletado

Você vai precisar deletar o arquivo primeiro e depois rodar esse comando


Um pequeno adianto na vida de linha de comando

Você pode ter ido embora sem ter feito o stage de arquivos, ou até deletado um arquivo e não ter dado o comando rm.. como você descobre o status atual da sua branch?

git status

Esse cara vai listar arquivos fora do stage, arquivos no stage, arquivos comitados.. enfim, um panorama geral do seu repositório

(esse é o menino dos olhos da @tati_fukuda)!

Mas o que é uma branch?

O Conceito de branch no git em poucas palavras é ter uma cópia do repositório principal e fazer suas alterações nela sem o risco de comprometer código estável.

Não é uma boa prática commitar e dar push no repositório principal chamado de master pois lá geralmente é onde fica o código estável da aplicação.

Por isso é sempre bom gerar uma branch local e depois subir ela, ou trabalhar direto na branch criada por outras pessoas.

Para saber em qual branch você está trabalhando atualmente, rode o comando:

git branch

Esse código vai mostrar todas as branchs que você tem localmente e com um * vai mostrar qual é a atual.

Para mudar a branch de trabalho atual, utilize o comando checkout:

git checkout nome_da_branch

Ou para voltar para master:

git checkout master

Se você por acaso digitou o nome da branch errado, você pode deletar ela localmente com:

git branch -d nome_da_branch_errada

E agora?

A tendência é expandir esse post com informações sobre rebase, merge e afins, coisas que geralmente testers deixam para desenvolvedores fazer pois é um pouco mais chato.

Se você tem alguma dica, manda ai nos comentários

Lembrando que meus posts estão ficando intinerantes, ou seja, alguns errinhos de português podem surgir.. não se sinta ofendido ou pense menos do meu trabalho por causa dele :)
Quem nunca esqueceu um ; que atire a primeira pedra!


Sobre o Autor: Leonardo Galani é Agile Tester, dev, gamer, dj and etc. Mantém o fórum http://agiletesters.com.br | http://leonardobg.com.br (profile)| http://lazytester.com (blog em inglês)
http://br.linkedin.com/in/leonardogalani/

comments powered by Disqus