Boas Práticas com GIT

Olá Mundo!
Neste artigo veremos como trabalhar com Git e as boas práticas em equipe.

O Git é uma plataforma gratuita que auxilia as equipes de desenvolvimento no controle da configuração de software (Software Configuration Management – SCM). Ele permite criar várias versões de um projeto, gerenciar estas versões com uma equipe e persistir as alterações em um servidor local ou remoto.
É necessário atentar-se às boas práticas de trabalho com o Git, pois um comando errado, ou uma alteração indesejada pode por em risco todo o trabalho da equipe.
Então vamos lá aprender um pouco sobre o Git.

Iniciando com o Git

Para iniciar um novo projeto, vamos dentro do diretório de nosso projeto – sitedaempresa – e usar o comando:

$ git init
$ git status
Os comandos iniciais - init e status
Os comandos iniciais – init e status

Este último comando traz as informações do diretório, porém ainda não temos nada de interessante acontecendo. Vamos, então, adicionar um novo arquivo chamado index.html. Feito isso rodamos o comando de status novamente.

arquivos não rastreados (untracked) pelo git
Arquivos não rastreados (untracked) pelo git

É possível verificar destacado em vermelho o arquivo que acabamos de adicionar ao diretório do git. Ele não está rastreado (untracked) isso significa que o Git sabe que existe uma alteração no arquivo, porém ele não está na lista para ser persistido – Staging Area.
Adicionamos o arquivo ao Staging Area com o seguinte comando:

$ git add index.html
Adicionando o arquivo ao staging area
Adicionando o arquivo ao staging area

O arquivo foi adicionado ao Staging Area e está pronto para ser persistido. Vamos fazer um commit para persistir o arquivo:

$ git commit –m “primeiro commit”
Commit do arquivo
Commit do arquivo

A opção –m do comando permite adicionarmos um texto ao commit sem a necessidade de abrir um editor de texto, como o Vim, por exemplo.
Pronto! Fizemos o primeiro commit e as mudanças do arquivo estão persistidas no repositório git. Para sabermos de todos os commit realizados podemos utilizar o comando de log:

$ git log
Registros de commits do repositório
Registros de commits do repositório

O Git nos informa a hash do commit, o autor e a data. A hash é um identificador único de cada commit. Ela é importante para podermos reverter uma versão ou visualizar as alterações de um determinado commit.
Por falar em versão, é possível adicionar ao diretório do git uma tag, que nada mais é do que um indicador da versão em que se encontra o projeto:

$ git tag v1.0
$ git tag

Este último comando lista todas as tags adicionadas ao projeto.

Boa prática – ambientes diferentes de desenvolvimento

Vamos continuar alterando nosso arquivo. Porém é importante termos em mente que uma boa prática ao se trabalhar com desenvolvimento em equipe, é criar um ambiente separado do ambiente principal, desta forma, evitamos problemas futuros, caso alguma coisa dê errado.
No Git é possível criar vários ambientes, conhecidos como branch . Pode ser criado um número infinito de branches, porém é bom termos bom senso e criar apenas aquelas branches significativas para nosso projeto.
Vamos usar o seguinte comando:

$ git checkout –b frontend

O comando checkout irá criar uma branch ‘’frontend’, caso ela não exista. A opção –b muda automaticamente para a nova branch.
É possível ver quantas branches existem no projeto com o seguinte comando:

$ git branch
Criando e visualizando as branches do projeto
Criando e visualizando as branches do projeto

Notamos pela imagem que existe no projeto a branch master. Esta é a principal branch de um repositório git. Na imagem rodamos o comando status, podemos ver que ele indica a branch atual em que estamos.
Finalmente, hora de algumas alterações!

Boa Prática – Commits pequenos e informativos

Na branch frontend vamos alterar o arquivo index.html adicionando o título da página na tag title e h1.

Alteração no title e h1 do index.html
Alteração no title e h1 do index.html

Ao rodarmos o comando ‘git status’ o Git indicará que há arquivos a serem adicionados ao Staging Area, então, vamos realizar um add e depois um commit.

$ git status
$ git add .
$ git commit –m “add title e h1”
Segundo commit do arquivo index.html
Segundo commit do arquivo index.html

O comando “git add .” adiciona todos os arquivos do working tree ao staging area.
Neste commit realizamos pequenas modificações (mínima, dado o tamanho do nosso projeto). Porém, é uma boa prática realizar commits menores, pois facilita a manutenção e evita conflitos de versões entre os arquivos.
Outra boa prática é a escolha de uma mensagem clara e concisa. Com isso é possível saber exatamente o que foi alterado em cada commit e assim poder reverter uma versão ou escolher um commit adequado para compor uma nova versão.
Vamos olhar nossos commits, agora um pouco mais detalhados.

$ git log --decorate
Registro mais detalhados dos commits
Registro mais detalhados dos commits

Pela imagem podemos observar as informações básicas do commit, mais informações extras como a versão e a branch em que o commit está.
Obs: A palavra HEAD é um apontador do Git. Ele indica qual foi o último commit e cria uma referência para ele.

Boa prática – uso de tags

Vamos adicionar uma nova tag e ver a diferença entre as versões

$ git tag v1.1
$ git diff v1.0 v1.1
Diferença entre as versões v1.0 e v1.1
Diferença entre as versões v1.0 e v1.1

Na imagem observamos que o Git mostra em vermelho as exclusões realizadas no arquivo e em verde são as novas inclusões. Desta forma, é mais rápido e prático usar as tags para enxergar as diferenças entre os commits.

Merge e Rebase

Vamos retornar agora para a branch master.

$ git checkout master

A branch está com o arquivo em uma versão desatualizada se olharmos no arquivo index.html podemos observar que ele não possui a tag title nem a h1 preenchida.

$ git show f9f34bb
Arquivo index.html com a versão antiga
Arquivo index.html com a versão antiga

Obs: Se abrirmos o arquivo com o editor de texto veremos que a versão é automaticamente alterada para a versão antiga.
Vamos atualizar este arquivo com as informações atualizadas da branch fronted. Para isso usamos o comando merge:

$ git merge frontend

Indicamos a branch a qual queremos mesclar. O Git automaticamente mescla as informações, se houver algum conflito ele irá indicar para podermos fazer as alterações necessárias.
Primeiro vamos adicionar a tag meta no index.html.

$ git commit -a –m “add tag meta”

A opção –a foi utiliza para pular a fase de staging area, desta forma o Git já realiza este passo automaticamente para nós.
Agora vamos fazer uma alteração na tag h1 do index.html. Vamos modificar o texto de “Bem vindo a Empresa XYZ!” para “Este é o site da empresa XYZ, seja bem vindo!”.

$ git commit –a –m “alterado texto h1 da empresa”

O arquivo index.html fica assim:

Arquivo index.html com texto da tag h1 alterado
Arquivo index.html com texto da tag h1 alterado

Vamos agora utilizar um novo comando. Iremos primeiro voltar a branch frontend e trazer as atualizações da master. Faremos isso com o comando rebase.

$ git checkout frontend
$ git rebase master

Obs: Apesar de terem o mesmo resultado aparente, os comandos merge e rebase são diferentes. Enquanto o primeiro apenas traz as informações do commit atualizado, o segundo restaura totalmente a base de commits .

Uso dos comandos merge e rebase
Uso dos comandos merge e rebase

Podemos observar que a branch frontend está alinhada com a base da branch master. É uma boa prática sempre que começarmos um novo trabalho, verificar se estamos com a versão mais atualizada do projeto.
Quando há uma equipe muito grande em um mesmo projeto, conflitos são recorrentes. Por isso, para evitar retrabalho ou dores de cabeça com versões desatualizadas, recomenda-se primeiro fazer uma atualização do repositório, para então, continuar com o trabalho.
Obs: em repositórios remotos é o famoso ‘git pull -> git commit -> git push’. Primeiro atualiza a base do projeto com a versão mais recente, salva as alterações e no final envia ao repositório do projeto.
Vimos neste artigo uma pequena parte do que o Git pode fazer. E aí? Tem mais sugestões de boas práticas, comente logo abaixo!
Este artigo é baseado na documentação do git, disponível em: Git Book
Inté Mundo!

0 Comentários

Deixe um comentário

Seu endereço de e-mail não será publicado.