Matheus Tardivo

Code is poetry.

Pull Request Driven Development

Recentemente li um post muito interessante escrito pelo Zach Holman com o seguinte título: How GitHub Works: Be Asynchronous.

Esse é o segundo post de um total de três falando um pouco do modo de trabalho no Github. Segue os links para os outros posts:

A imagem acima não tem nada haver com o assunto desse post, mas não resisti colocar ela aqui. Essa é uma foto do Octobeer, o Kegerator do escritório do Github. Ou seja, enquanto aqui no iG convidamos os colegas de trabalho para tomar um café, lá eles tomam um choppinho – claro ou escuro :)

Bom, voltando ao assunto… Pela primeira vez tenho a oportunidade de trabalhar em um projeto com vários desenvolvedores que usam o Github como repositório de código. Até então usavamos o Mercurial. Apesar da semelhança entre o Git e o Mercurial, tivemos algum trabalho com a utilização do Mercurial que esperamos acabar ou pelo menos reduzir usando o Github.

E é ai que entra uma parte do texto do Holman: tornar o workflow de desenvolvimento assíncrono envolve a utilização de Pull Requests. Segue abaixo uma breve descrição dessa funcionalidade retirada do site do Github:

Pull Requests are living discussions that streamline the process of discussing, reviewing, and managing changes to code.

PRDD na prática

Uau… PRDD… Muito boa essa sigla ein? Já pensou você falando numa entrevista de emprego assim: Já trabalhei num projeto usando Rails, com BDD + TDD e PRDD. Com certeza será contratado na hora :)

Brincadeiras a parte, vamos entender na prática como funciona a utilização de Pull Requests no workflow de desenvolvimento.

Quando você for trabalhar na inclusão de uma nova funcionalidade ou então em algo que traga algum impacto no codebase do projeto, então crie um novo branch para isso. Um exemplo: um desenvolvedor vai trabalhar numa funcionalidade de streaming para o projeto resque-pastie (esse projeto é uma só uma brincadeira que fiz aqui para testar o Resque com Rails). Então vamos criar o novo branch streaming e já mudar para ele com o seguinte comando:

1
git checkout -b streaming

E faça o push desse branch para o repositório remoto:

1
git push github streaming

Quando terminar a codificação da funcionalidade, crie um Pull Request para esse branch: Acesse o repositório no Github e mude o branch de master para streaming e depois clique no botão Pull Request que fica a direita da tela. Veja a figura abaixo:

Revise o seu Pull Request e coloque os comentários necessários. Lembrando que o texto desse comentário será parseado pelo Github Flavored Markdown. Então você pode formatar o texto, incluir imagens, blocos de código e tudo mais que o parser do GFM suportar. Agora basta clicar no botão Send pull request para criá-lo.

O workflow agora está no ponto onde os demais desenvolvedores do projeto fazem a revisão do Pull Request criado. Você ainda pode fazer um deploy parcial desse branch em um ambiente de QA ou até mesmo em algumas máquinas de produção para testar o que foi feito, verificar se tudo está ok e então fazer o merge para o master. Segue uma imagem da tela de revisão do Pull Request:

Veja que neste caso, como a alteração realizada no código foi bem simples, o Github exibe um botão para fazer o merge automático do código.

Mesmo depois de criado o Pull Request, você e os outros desenvolvedores ainda podem fazer alterações e incluir outros commits nesse mesmo Pull Request. Basta fazer o push desses commit no mesmo branch, neste caso o branch streaming. Veja na figura abaixo que um outro commit foi incluído no mesmo Pull Request:

Agora vamos fazer o merge automático desse pull request. Para isso é só clicar em Merge pull request e depois em Confirm merge. Veja que o Pull Request foi fechado e as alterações feitas naquele branch agora estão no master.

Você também pode fazer o merge desse Pull Request manualmente pelo terminal. Para isso criei um outro branch com o nome de manual, fiz o commit do código alterado, o push desse branch para o repositório e criei um novo Pull Request.

Agora vamos fazer o merge:

O primeiro passo é mudar para o branch master:

1
2
$ git checkout master
Switched to branch 'master'

Não se esqueça de fazer o pull para obter as últimas alterações:

1
2
3
4
5
6
7
$ git pull github master
From github.com:matheustardivo/resque-pastie
 * branch            master     -> FETCH_HEAD
Updating d33046c..e63d721
Fast-forward
 README.md |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Agora faça o fetch do branch que originou o Pull Request:

1
2
3
$ git fetch github manual
From github.com:matheustardivo/resque-pastie
 * branch            manual     -> FETCH_HEAD

Faça o merge do brach:

1
2
3
4
$ git merge manual
Merge made by recursive.
 README.md |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

E finalmente o push para o master:

1
2
3
4
5
6
$ git push github master
Counting objects: 1, done.
Writing objects: 100% (1/1), 227 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:matheustardivo/resque-pastie.git
  e63d721..e2ad64a  master -> master

Entre no Github e você verá que o código do branch manual foi incorporado no master e o Pull Request foi fechado.

Bom, a ideia é essa. No decorrer da utilização do PRDD no nosso dia-a-dia com certeza irão surgir alguns problemas e talvez outras maneiras de lidar com o workflow de desenvolvimento, mas é importante ver o que ganhamos usando os Pull Requests: comunicação assíncrona, revisão do código por outros desenvolvedores, organização do repositório por funcionalidades desenvolvidas, possibilidade de testar tais funcionalidades isoladamente de forma simples e etc.

Não deixe de ler a documentação do Github sobre Pull Requests:

Comments