Precisamos falar sobre GIT (2)

Olá versionadores e versionadoras e plantão segue a segunda parte e conclusão do meu artigo sobre git. Ainda não leu? Não faz ideia do que é git? Ainda está no mundo do SVN? então clica aqui e depois volte certo?!?

Caso não se lembre na primeira parte montamos um ecossistema para que você consiga versionar sozinho e foi mostrado alguns comandos básicos, mas agora imagine que está programando em grupo e terá que lidar com conflitos, escrever mensagens de commit mais semânticas, trabalhar com diversas branches entre outros.

Primeiros vamos definir o significado de algumas coisas que iremos utilizar, e claro que irei explicar com minhas palavras, se deseja ver os termos técnicos clique aqui:

Branch - Equivale a uma "linha do tempo" do seu projeto, porém diferente do mundo real é possível ter várias "linhas do tempo" em um projeto e no final de tudo fundir (marge) todas essas linhas ou melhor dizendo ramos.

Veja o exemplo ao lado temos duas Branches que no final irão realizar marge com a Master, que será feito através de uma release ou lançamento do projeto.

Tag - Marcam as versões do seu projeto, basicamente equivale aos nomes que você dava aos seus projetos na faculdade como Agora-Vai.zip, versao-final2.zip ou versao-final-agora-vai154.zip, porém o git possui uma forma melhor para fazer isso, que se torna ainda mais elegante se utilizado com um padrão, atualmente utilizo da seguinte forma: em um versão 4.2.3 o 4 (primeira posição) se alteraria no caso de uma mudança que causasse incompatibilidade com as versões anteriores, o 2 (segunda posição) seria alterado nos casos de novas funcionalidades e o 3 (terceira posição) para manutenções ou correções, porém exitem vários padrões exemplo a SemVer como descrito aqui.

No exemplo ao lado podemos ver algumas Tags que foram criadas, basicamente é mostrado a versão que no caso ao lado é 0.0.2 e uma mensagem que deixei igual a versão da Tag, porém é possível escrever uma mensagem mais descritiva.

Agora que já sabe esses conceitos podemos prosseguir no nosso git flow é enviar nossas alterações para a master criando uma nova tag. Agora que está trabalhando em equipe vale ressaltar que é de bom tom "commitar" apenas aquilo que diz respeito a sua mensagem de commit exemplo: git commit -m "Altera tela de login". Suas tags que basicamente são um grupo de commits ficam mais rastreáveis auxiliando no rastreio de bugs, melhorias continuas, documentação do projeto entre outros, e por ultimo lembre-se tags "nunca" são demais, então crie com certa frequência para melhor controle das suas versões.

Vamos aos comandos. Abaixo vou deixar a lista de comandos que iremos utilizar em seguida o passo a passo.

Dicionário de comandos:

• git flow init - Inicia as configurações do git flow
• git flow release start 'numero da sua versão' - Inicia uma nova release.
• git flow release finish 'numero da sua versão' - Finaliza uma versão especifica.
• git push origin develop master --tags - Envia as alterações para as branches develop e master. A tag criada no git flow start também será enviada.

1 - Baixando projeto do git (git clone 'repositório') :

2 - Agora vamos iniciar nosso git flow (git flow init):

Após realizar o comando algumas configurações podem ser feitas, a principio recomendo utilizar a padrão, bastar apertar Enter até que as perguntas terminem, porém se para sua equipe for interessante deixar um prefixo antes das suas tags (Ex: Versão 0.1.2), ou alterar a branch que irá para produção, ou alterar a branch que servirá de base para a release fique a vontade, mas sugiro uma pesquisa prévia antes, de todo modo as configurações padrão irão nos atender perfeitamente.

Note que o comando criou uma branch local chamada develop e já nos redirecionou para ela (Mudar de branch: git checkout 'Nome da branch') que é onde devemos desenvolver, ou seja, sempre que realizar clone em um repositório faça o comando logo em seguida, se fizer alguma alteração diretamente na master você pode ter diversos problemas de conflito.

Agora você pode desenvolver tranquilamente seu projeto seja apenas na develop (que está local na sua maquina até o momento) ou em várias outras branches isso vai depender do seu time, porém no final todas elas devem realizar merge com a develop, confirme configuramos acima, ela servirá de base para novas releases. O comando git merge (sessão atualizar e mesclar) pode te auxiliar a trazer essas alterações de outras branches para a develop.

2 - Iniciando o git flow (git flow init):

Agora vamos iniciar a nossa release eu irei executar o comando git flow release start 0.0.3 conforme mostrado abaixo:

Você deve executar o comando git flow release finish 0.0.3 logo em seguida. O processo é um pouco diferente, primeiro todas as mudanças são feitas em seguida ela é iniciada e finaliza na sequência.

3 - Adicionando mensagem a release:

Nessa etapa iremos realizar as considerações finais que são adicionar mensagem a nossa release e enviar para o repositório, por padrão o git tem o Vim como editor de texto, mas é possível mudar caso queira, a principio recomendo seguir com ele e mudar no futuro.

Quando o comando git flow release finish 0.0.3 terminar de ser executado você verá a seguinte tela, nela basta apertar Esc, em seguida escrever :x (Dois pontos X sem espaço) e apertar Enter, lembrando que esses comandos são do Vim e como supracitado pode ser alterado.

Em seguida será solicitado alguma mensagem descritiva para a sua tag, note que os asteriscos são comentários, para escrever basta apertar Insert, agora será possível escrever no documento, para fechar e salvar utilizamos Esc em seguida :x (Documentação Vim).

Por último será mostrado o resumo das coisas que foram feitas como versão e mensagem, basta fechar e prosseguir (Esc + :x).

Até o momento tudo que fizemos permanece local, para realizar push para o repositório teremos que executar o seguinte comando: git push origin develop master --tags.

Pronto você conseguiu fazer uma release utilizando o git, é claro que todo esse processo pode ser simplificado utilizando ferramentas como aliases, git desktop ou tortoiseGit, porém resolvi mostrar de forma um pouco mais transparente, vale lembrar que mesmo o git flow executa diversos comandos por baixo dos panos.

Recomendo a leitura de todos os materiais vinculados ao artigo na forma de hiperlinks e como estamos falando de desenvolvimento em time, saber o que é um pull request é bem válido. Sigo disponível para dicas ou criticas construtivas nos comentários.

Até a próxima pessoal!