Merge pull request #35 from geidsonc/feature/sugestao-texto-pr

Altera parágrafo sobre colaboração com branch e sugere leitura sobre modelos de desenvolvimento colaborativos.

Author: gomex

Diff for: manuscript/colaboradoras.md

@@ -1,6 +1,6 @@
 # Colaboradoras
 
-Aqui está a lista de pessoas que colaboraram com Pull Request (PR) para este livro :sparkles:. 
+Aqui está a lista de pessoas que colaboraram com Pull Request (PR) para este livro :sparkles:.
 
 - [Adail Horst](https://github.com/SpawW)
 - [Vinícius Mamoré](https://github.com/vmamore)
@@ -10,6 +10,7 @@ Aqui está a lista de pessoas que colaboraram com Pull Request (PR) para este li
 - [Kelvin Salton](https://github.com/kelvins)
 - [Paulo Gonçalves](https://github.com/PauloGoncalvesBH)
 - [Ricardo Tássio](https://github.com/ricardotassio)
+- [Geidson Benício](https://github.com/geidsonc)
 
 Meu muito obrigado por melhorarem o material e assim contribuirem para toda a comunidade :tada:.
 

Diff for: manuscript/o_que_e_pr.md

@@ -33,23 +33,25 @@ Se a funcionalidade for feita no mesmo local de código mas em linhas diferentes
 
 A sugestão é que funcionalidades diferentes sejam tratadas de forma isolada, a fim de não causar conflito algum no processo.
 
-Todo esse processo que descrevi aqui, pode ser feito também baseado em branch, mas a pessoa que colabora precisa ser membro do repositório e não uma pessoa aleatória na internet, pois ela precisa ter permissão para criar branch no repositório. No fim é o mesmo propósito, mas ao invés de repositório inteiro, tudo que expliquei aqui acontece no nível de ramificações.
+Todo esse processo que descrevi aqui, também pode ser feito em um modelo baseado em branch. Nesse modelo a pessoa que colabora precisa ser adicionada como membro do repositório, ter permissões para criar branch e ter acesso a push (empurrar mudanças). Esse é um modelo muito usado por equipes e empresas que colaboram em projetos privados.
 
-Por fim, note que em outras plataformas de repositórios online, o conceito de Pull Request pode ter outros nomes como por exemplo Merge Request(Requisição para mergear).
+Se você quiser conhecer mais sobre esses dois modelos de desenvolvimento colaborativo, sugiro aprofundar a leitura em [Sobre modelos de desenvolvimento colaborativo](https://docs.github.com/pt/github/collaborating-with-pull-requests/getting-started/about-collaborative-development-models)
+
+Por fim, note que em outras plataformas de repositórios online, o conceito de Pull Request pode ter outros nomes como por exemplo Merge Request (requisição para mergear).
 
 ## Como usar Pull Request para o processo de revisão?
 
 A maioria das organizações utiliza o Pull Request como mecanismo padrão para revisão de código, pois ele é basicamente a "porta de entrada" para a base "oficial" de código, seja em relação ao repositório ou branch.
 
 Normalmente as branchs que serão usadas para construir o artefato final do repositório oficial são protegidas e não podem receber commits diretos, ou seja, tudo que entra nessas branchs devem entrar por um PR (Pull Request). Existe a possibilidade do administrador do repositório mandar o código direto, mas isso deve ser apenas uma exceção. Dito isso, eu reforço, **mesmo os administradores do repositório**, **pessoas desenvolvedoras experientes**, ou até mesmo a **liderança técnica** do time devem mandar suas mudanças por PR e elas devem ser avaliadas por outras pessoas.
 
-Quando começar a trabalhar em uma funcionalidade nova do repositório. Eu faço parte da organização? Tenho acesso a criar uma branch? Caso positivo, eu crio uma branch.
+Quando começar a trabalhar em uma nova funcionalidade do repositório, verifique se você faz parte da organização e tenho acesso a criar uma branch. Caso positivo, crie uma branch.
 
-Existe um Padrão para criação de branch? Eu gosto do modelo "feature/nome-da-funcionalidade" assim fica muito claro para todo mundo no que você está trabalhando. Se você usa algum sistema de ticket para gerenciar as tarefas você pode colocar o identificador do ticket também: ""feature/nome-da-funcionalidade#435".
+Existe um padrão para criação de branch? Eu gosto do modelo "feature/nome-da-funcionalidade" assim fica muito claro para todo mundo no que você está trabalhando. Se você usa algum sistema de ticket para gerenciar as tarefas você pode colocar o identificador do ticket também: ""feature/nome-da-funcionalidade#435".
 
 ![Proposta de fluxo para Pull Request](resources/images/pullrequest2.png)
 
-Lembre-se que sua branch precisa ser bem específica, ou seja, se "aparecer" outra demanda, o aconselhável é abrir outra branch a partir de branch "oficial" (que normalmente é a "master").
+Lembre-se que sua branch precisa ser bem específica, ou seja, se "aparecer" outra demanda, o aconselhável é abrir outra branch a partir de branch "oficial" (que normalmente é a "master" ou "main").
 
 Quando você tiver muita confiança que seu código entrega tudo que a funcionalidade precisa para existir, você deve abrir um PR e na descrição desse PR você deve detalhar qual comportamento esperar dessa mudança que você está propondo.
 
@@ -98,6 +100,8 @@ A maioria das organizações seguem alguns padrões para como escrever código,
 
 Esse padrão deve estar claro em algum lugar, e a pessoa que vai colaborar deve ler isso antes, mas nem sempre isso é possível e dessa forma a colaboração pode não seguir esse padrão. Você que está avaliando deve deixar bem claro para esta pessoa qual regra ela está infligindo e qual parte do código isso acontece. O github oferece a funcionalidade de comentar nas linhas do código do PR.
 
+Algumas discussões sobre detalhes de padrões podem ser tratadas e revisadas automaticamente com uso de ferramentas, como um bom formatador e um linter, que ajuda a economizar muito tempo da equipe com as revisões.
+
 ![Comentário no review](resources/images/pullrequest4.png)
 
 Depois que comentar todo o PR não esqueça de finalizar sua revisão, caso contrário a pessoa que fez o PR não verá seu comentário.