From 430d26ab9d4e676facc6d954a36efd9b1ba06f00 Mon Sep 17 00:00:00 2001 From: Pedro Lucas Porcellis Date: Tue, 18 Nov 2025 01:25:45 -0300 Subject: [PATCH] Ajusta o texto explicando sobre usar o git no formato tradicional MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit O texto original tinha alguns problemas porque sugeria que o modelo do GitHub é um modelo superior e novo, que inclusive ele por si só ajudava a "ter menos bugs porque existe revisão", o que simplesmente não é verdade. Sim, o modelo de Pull Requests é mais centralizado e faz sentido quando pensamos numa plataforma centralizada como o GitHub, instâncias do GitLab, etc. Mas ele não é a prova de balas e também introduz problemáticas (como a política de adicionar milhares de commits "fix bug" num PR a cada revisão, estas que o próprio GH visa corrigir com a funcionalidade de Squash Merge, por exemplo). Enfim, tentei destacar que o modelo antigo tem suas vantagens e tampouco é "antiquado" ou "ruim" (até porque, o maior projeto open-source do mundo usa ele em escalas que nenhum outro projeto sonha em fazer usando listas de email, por exemplo), sem entrar muito em detalhes porque eu acho que falta uma parte mais "avançada" pra se debruçar em cima do modelo de patches. Talvez pudesse ser o capítulo 5, mas provavelmente precisaria refatorar e reorganizar todas as referências? --- ...10.1-o-que-e-um-pull-requests-no-github.md | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md b/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md index 78f5c75..6d7caab 100644 --- a/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md +++ b/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md @@ -7,17 +7,35 @@ Imagine que um grupo está escrevendo um livro em conjunto. Cada pessoa escreve * Ele é um pedido para que alterações sejam revisadas e incorporadas ao projeto. * Em vez de modificar diretamente o código do projeto, a pessoa sugere mudanças e pede a aprovação de outras pessoas. -## Como Era Feito Antes? - -Antes da existência dos PRs, colaborar em um projeto era muito mais complicado. Imagine que duas pessoas estão escrevendo um livro juntas, mas cada uma está usando um caderno diferente. Para juntar os textos, era preciso mandar as páginas por carta ou e-mail, e a outra pessoa teria que copiar e colar manualmente no livro final. Se houvesse erros ou sugestões, o processo de revisar e modificar seria bem mais demorado. - -No mundo do desenvolvimento, antes dos PRs, as mudanças no código eram enviadas por e-mail em arquivos separados. Quem administrava o projeto tinha que baixar, comparar e juntar tudo manualmente, o que aumentava o risco de erros e tornava a colaboração muito mais lenta. - -Os **PRs foram criados para facilitar esse processo**, trazendo: - -* **Revisão de código integrada**: Outras pessoas podem comentar e sugerir melhorias. -* **Histórico claro de alterações**: O GitHub mostra exatamente o que mudou. -* **Menos erros**: Como há revisão antes da fusão (merge), menos _bugs_ chegam ao código principal. +## Outros modelos... + +O GitHub introduziu o modelo de Pull Requests, como uma visão alternativa para o +modelo tradicional que o git foi desenvolvido. Funcionalidade essa que foi adota +por outros serviços de hospedagem de código, como o GitLab, Bitbucket, codeberg, +entre outros. Lembre-se, o git em si é um sistema distribuido de controle de +versão, e não uma plataforma centralizada de hospedagem de código. Isso +significa, entre outras coisas, que o git foi desenvolvido para ser trabalhado +de forma distribuida, através do e-mail, que por si só é um sistema distribuido +(você pode enviar e receber e-mails de qualquer provedor do mundo). Portanto, o +git, em sua essência, tem a habilidade de distribuir os códigos e mudanças +gerando um patch (remendo em inglês) que pode ser enviado por e-mail para +qualquer pessoa, e essa pessoa pode aplicar esse patch em seu repositório local. + +A parte do distribuido entra nesse aspecto, porque, esse modelo, para funcionar +(tal qual o kernel do Linux, o próprio git, e muitos outros projetos open +source) precisam ter uma lista de emails para onde essas mudanças são enviadas e +naturalmente, qualquer pessoa que subscrevesse essa lista de e-mails poderia +contribuir com a discussão e o desenvolvimento do projeto. Esse modelo é, +naturalmente, mais complexo e mais lento do que o modelo de Pull Requests, +visando que o mesmo consegue centralizar e manter referência de todas as +mudanças propostas em um único lugar, facilitando a revisão e o gerenciamento +das contribuições. + +Os **PRs facilitam esse processo em um modelo mais centralizado**, trazendo: + +* **Revisão de código integrada**: Outras pessoas naquele repositório podem comentar e sugerir melhorias. +* **Histórico claro de alterações**: O GitHub mostra um histórico das versões e o que mudou. +* **Integração com outras funcionalidades do GitHub**: O GitHub pode rodar testes automáticos, verificar conflitos e muito mais. ## O nome "Pull Request"