Template de Pull Request

Normalmente, quando um time usa um repositório Git, seja hospedado no Github, Bitbucket ou num GitLab privado, há sempre uma discussão sobre como controlar os pull requests feitos por cada um.

Cada pessoa tem seu jeitinho de fazer as coisas, e isso pode começar a ficar complicado quando o time começa a escalar.

Faz pouco tempo que decidimos usar um template de pull request aqui no trabalho e isso tem ajudado bastante no code-review.

Antes de continuarmos, vamos só alinhar alguns pontos pra que você acompanhe o texto tranquilamente.

O que é pull request?

Se não está familiarizado com o termo, um pull request nada mais é do que uma solicitação de merge de um branch que você esteja trabalhando para o branch principal (normalmente o master, ou develop).

Usando pull requests, você consegue aprovar antes determinadas funcionalidades de outras pessoas para o seu projeto. Isso faz com que o "controle de qualidade" seja maior.

Trabalhando com features

Geralmente usamos o Git Flow pra controlar a criação e todo o fluxo de novas features. Não vou me aprofundar muito nesse assunto, pois merece um post à parte.

Quando criamos branches, que chamamos de "features", cada um deles precisa ser uma funcionalidade independente pra haver a realização de um deploy individual e os testes sejam específicos.

Sendo assim, ao finalizar o desenvolvimento, os devs criam pull requests para o branch principal - no nosso caso, o develop.

Ao criar o PR, você tem alguns campos pra preencher: título, descrição, tag... Parece simples, basta preenche-los e ok. Só que não.

Cada um tem seus métodos de escrever e organizar coisas. Até mesmo a forma de escrever commits é diferente de um pra outro.

Por isso, pra mantermos as coisas mais fáceis de entender e sem nenhuma falha de comunicação, foi necessário um template de criação desses PRs.

Criando um template de PR

Nós começamos a discutir isso e chegamos num consenso de um modelo ideal de template.

Esse exemplo é uma demonstração de uma feature simples, uma nova funcionalidade que queremos "subir" para o ambiente de testes.

Exemplo de pull request

*CHANGELOG* :memo:
  * adding some validations to contact form;
  * adding jQuery Validate to the project;
  * creating module to wrap jQuery Validate;

*CARDS* :cards:
  * [Adding validations to contact form](https://trello.com/abcdef)

O exemplo acima demonstra como criar um PR que adiciona uma funcionalidade de validação de formulário de contato ao projeto.

A primeira parte (CHANGELOG) contém as alterações que foram feitas no código. Essa descrição é importante pra que, o desenvolvedor que for aprovar tenha uma visão geral do que foi feito.

Nessa área é necessário preencher com as informações mais importantes da alteração, sempre de forma breve e objetiva.

A segunda parte (CARDS), serve para colocar links relacionados ao seu gerenciador de tarefas do projeto, seja ele Trello ou Jira, por exemplo.

É importante colocar isso, pois geralmente esses cards contém as informações de negócio que são necessárias para o teste ser validado.

Exemplo de pull request de uma feature

Bugfixes

Mas e no caso de bug fixes? Mantemos praticamente a mesma estrutura, apenas alterando de CHANGELOG pra BUGFIXES, e a descrição se mantém da mesma forma - resumida, mas com as alterações feitas.

Exemplo de PR de um bugfix

Disseminação de cultura

Eu sempre prego que, pra que um método ou processo seja adotado por todos, é necessário que todos participem da decisão que levou à esse item. Sem isso, a chance do uso do modelo falhar é grande.

Nós nos reunimos pra discutir, numa mini-reunião, e acabamos saindo com esse template simplificado. À partir daí todos foram adotando sem muita dor, já que tinham participado da escolha do template e do formato.

Durante um tempo, deixamos impresso o markdow com a descrição do modelo e colamos na parede imantada aqui do escritório, pra todos poderem ver e opinar com post-its caso surgisse uma nova ideia.

Template implementado

Hoje, já é automático pra nós. Ao abrir um pull request sempre colocamos o modelo decidido por todos.

É bacana que, quando alguém esquece, logo outra pessoa cobra a alteração pra se encaixar no modelo. Assim nos auto-gerenciamos nessa questão sem muita burocracia, mas com uma cultura criada por nós mesmos.

Você também usa algum template na sua empresa? Comenta aqui e compartilha com a gente!

comments powered by Disqus