Adaptando o time ao Git

No começo do projeto, nosso time do ARDA tinha 4 desenvolvedores ativos.

O primeiro passo foi criar um repositório Git para começarmos a trabalhar no código.

Por que criar um repositório de código?

Essa é uma das perguntas que não sei responder – como é que alguém consegue trabalhar sem controle de versão? Eu sei que é possível e que algumas pessoas guardam o código no HD da própria máquina ou então no DropBox, mas não faça isso. Isso é tão errado quanto um DBA que não faz backup do banco de dados.

No dia a dia, uso bastante o GitHub e VSTS, mas há também o BitBucket, GitLab, entre outros.

Se definir o repositório Git é o primeiro passo, qual seria o segundo passo?
Resposta: Precisamos adaptar o time ao Git.

Organizando os Branches

Em desenvolvimento mais simples, você pode usar o branch master para tudo. Acho que o limite é de até 2 pessoas colaborando simultaneamente, porque logo mais começa uma bagunça.

No nosso caso, usamos os branches master (produção), sprint (desenvolvimento) e feature branches (um para cada usuário/feature).

Como nosso processo de CI/CD rodava sobre o branch sprint, praticamente não dependíamos do branch master. Houve inúmeras ocasiões que o master ficava desatualizado… enfim, histórias que ninguém precisava ficar sabendo (hehe).

No mercado, existe um fluxo chamado de Gitflow Workflow.

Gosto desse tutorial da Atlassian, que fala sobre as diferentes workflows:

• Centralizado
• Feature branches
• Gitflow
• Forking

Gitflow Workflow
https://www.atlassian.com/git/tutorials/comparing-workflows

Posso dizer que o workflow Centralizado não funciona para nossa equipe quando há mais de 2 pessoas trabalhando. Implementamos o Feature branches com sucesso, embora muitas vezes ele se tornava User branches (criação por usuário ao invés de feature). Queríamos chegar ao nível do Gitflow com todo o processo de dev, master, release, mas nunca sentimos essa necessidade. Por fim, forking workflow é um exagero para nossa necessidade – talvez se houvesse milhares de contribuições da comunidade?

Pull Request (PR)

Uma funcionalidade muito bacana disponível no VSTS (e GitHub) é o Pull Request (PR) .

Vamos supor que o nosso estagiário esteja trabalhando ferozmente no código, mas não queremos dar acesso de escrita no branch master.  Então marcamos o master como read-only e permitimos somente a criação de novos feature branches. Quando houver código para ser consolidado no branch master, então é enviada uma solicitação de PR.

Dessa forma, temos a chance de revisar o código antes de fazer o merge.

No exemplo abaixo, vemos uma série de PR enviados para aprovação – inclusive nosso estagiário mandando “gambi removed”.

Embora o Pull Request seja uma ferramenta poderosíssima, demoramos um tempo para implantar e depois de um tempo deixamos de usá-la. O motivo é que a revisão era completamente desnecessária pois ninguém efetivamente revisava o código. Revisar as solicitações e as mudanças requer tempo, por isso, é necessária uma pessoa dedicada ao processo de PR para implementá-lo adequadamente.

Histórico de Commits

As ferramentas online do VSTS são muito boas. Aqui podemos ver o histórico visual: se voce prestar atenção, vai notar que o primeiro commit 4a6b7685 foi feito em um “user branch”, enquanto que a PR #9 foi feita sobre um feature branch correspondente ao commit 79ed283f.

Sem dúvida, há espaços para melhorias: squash commits, rebase, etc. Felizmente nunca tivemos problemas em manter a bagunça do histórico desse jeito.

 

Conclusão

Não há dúvidas de que somos dependentes do Git para desenvolver e nosso próprio processo tem vários pontos de melhoria:

• Usar git rebase para manter um histórico linear
• Adotar o gitflow como workflow de trabalho
• Forçar somente merge por pull requests
• Fazer o squash commit (junto com o rebase) para retirar os commits intermediários

Nunca implementamos nada disso e ainda planejamos essas tarefas. Acredito que a resposta seja diferente em ambiente com um maior número de colaboradores. No nosso caso, porém, ainda não temos escala para agregar esses pontos ao processo de desenvolvimento. É importante saber a hora de empregar cada uma dessas técnicas - caso contrário, elas podem se tornar apenas uma burocracia adicional.

Parece que adaptamos o Git ao time e vice-versa.

Comments

• Anonymous
  August 11, 2017
  Muito bacana Catae.Já usei o Git em projetos da faculdade e acho indispensável para quem maneja código diariamente.Aqui no trabalho temos um ambiente replicado com incontáveis assinantes e procedures customizadas e estou maturando a idéia pra controlar essas procs via Git.Abraço!
  • Anonymous
    August 14, 2017
    Concordo! Estou 100% dependente do Git.