O documento descreve o que são pull requests e como eles podem ser usados em times pequenos. Pull requests permitem que contribuições sejam feitas e revisadas de forma assíncrona e aumentam a rastreabilidade do código. Eles estabelecem comunicação entre desenvolvedores e mantenedores de projetos.

1. Pull requests
SG TECH

2. PRÉ-REQUISITOS

3. ANTES DE FALAR DE PULL REQUESTS
• Lembrando que este treinamento pressupõe que você entenda:
– O que é versionamento de código;
– GIT e suas características;
– TFS;
• Chamaremos nesta apresentação:
– Pull Requests de PR´s;
– Product Backlog Item de PBI;

4. PARA QUE SERVE ?

5. PARA QUE SERVE
• Um pull request originalmente serve para que pessoas possam contribuir para
projetos “Open Source” sem modifica-los diretamente.
• Ele se baseia nas seguintes premissas:
– Um contribuinte está enviando mudanças que considera como melhorias para um
repositório sem afetá-lo diretamente. A contribuição inclui uma descrição do objetivo da
melhoria, a melhoria em si e suas credenciais;
– Uma ferramenta gerencia esta intermediação.
• Estabelece a comunicação entre o contribuinte e o mantenedor do projeto;
• Permite o “merge” online;
• Guarda o histórico da mudança.

6. PQ USAR EM TIMES PEQUENOS ?
– Permite que mudanças possam acontecer de maneira assíncrona;
– Zera a dependência de aprovação mútua para objetivar a integração contínua;
– Permite um fluxo claro de “code review”;
– Aumenta a rastreabilidade;

7. DESAFIOS
– Como lidar com a lista de branches nas máquinas ? Nos testes as branches que foram
marcadas para serem excluídas continuaram nas máquinas dos colaboradores. Isto
aumenta o tamanho do repositório e precisamos pensar em como excluir isto.
– Como sensibilizar que bugs urgentes ainda precisam de PR sendo que temos pressa ?

8. COMO FAZER ?

9. COMO FAZER
– Partimos do princípio que todos os
PBIs que geraram modificação em um
dos repositórios gera a criação de uma
nova branch, passamos a anexar a
branch no PBI;
O ciclo de desenvolvimento passa a ser análise, desenvolvimento, teste, solicitação de PR
(feito por quem testou);

10. COMO FAZER
– Partimos do princípio que todos os
PBIs que geraram modificação em um
dos repositórios gera a criação de uma
nova branch, passamos a anexar a
branch no PBI;
O ciclo de desenvolvimento passa a ser:
Bug / Task Análise
Desenvolvi
mento
Teste
funcional
Solicitação
de PR

11. E DEPOIS ?
– Quando for conveniente, solicitar urgência no code review;
– O code review vai ocorrer e a sua funcionalidade vai ser “mergeada” com a master e
publicada dentro do cronograma;
– Eventualmente você pode ser notificado a corrigir / alterar alguma coisa em função de não
conformidade;

12. COMO É O CODE REVIEW?
– Quando for conveniente, solicitar urgência no code review;
– O code review vai ocorrer e a sua funcionalidade vai ser “mergeada” com a master e
publicada dentro do cronograma;
– Eventualmente você pode ser notificado a corrigir / alterar alguma coisa em função de não
conformidade;

13. COMO TRATADO UM PR ?

14. PRINCIPAIS FUNCIONALIDADES
– Uma timeline pública discute a implementação;
– É possível aceitar, deletar, rejeitar com sugestões, aceitar com sugestões;
– Revisar cada um dos arquivos afetados no repositório e sua linha de tempo específica;
– Revisar cada um dos Work Items afetados por esta PR;
– Merge pela ferramenta online;

15. VALE A PENA LER +

16. OPINIAO NA WEB
Sobre o assunto:
• https://www.quora.com/Does-using-Git-pull-requests-make-sense-on-small-teams-
projects
• https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests
• https://yangsu.github.io/pull-request-tutorial/
• Vale a pena ler:
• https://dev.to/backendandbbq/pull-requests-the-good-the-bad-and-the-ugly
• https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/

17. ATÉ A PRÓXIMA