Por que usar solicitações pull em vez de mesclar

Qual é a vantagem de usar solicitações pull em vez de simplesmente mesclar uma ramificação no master sem uma? Particularmente em uma equipe em que todos os desenvolvedores têm acesso total ao mestre.

As solicitações pull fornecem verificações e saldos, mesmo que alguém possa pressionar para dominar.

A maior vantagem é que eles oferecem uma oportunidade para revisão de código. A pessoa responsável por executar o pull pode examinar o código e os testes e garantir que eles atendam a qualquer tipo de diretrizes que a organização ou equipe possua. Também existem outros motivos para a revisão de código - educação, localização de defeitos ou aprimoramentos, treinamento cruzado da equipe no sistema, oferecendo aos testadores uma visão em branco do sistema.

Se a pessoa que executa o pull estiver familiarizada com a arquitetura do sistema, poderá garantir que as mudanças se ajustem à visão arquitetônica do sistema, especialmente se a equipe inteira não tiver a visão de longo prazo.

O desenvolvimento do hábito de usar solicitações pull também pode ajudar sua equipe se você decidir no futuro que toda a equipe não deve ter acesso ao mestre. Se sua equipe crescer, e principalmente se você tiver novos membros do produto e / ou novos no Git, não permitir que eles acessem o mestre pode ser mais seguro para a integridade do produto.

Tendo feito solicitações de ramificação e garfos de recursos + pull, acho que os pedidos pull oferecem pouca vantagem quando todos vocês estão desenvolvendo na mesma equipe ou empresa

Eles oferecem um bom mecanismo e interface para a revisão de código, mas também complicam e desaceleram todo o processo de 'concluir as coisas'. Especialmente se você tiver muitos recursos pequenos, cada um aguardando revisão, mesclando e todos os outros sendo mesclados com o mestre novamente para obter as alterações, etc. .

Dito isto, você pode fazer solicitações pull entre filiais no mesmo repositório. Você não precisa se bifurcar ou possui permissões diferentes.

Além disso, você deve considerar toda a metodologia e o fluxo de trabalho. Você também tem um sistema de emissão de bilhetes, IC, testes de aceitação automatizados etc.? Suas análises de código fornecem uma verificação única e vital antes da ativação dos códigos ou são apenas exercícios de carimbo de borracha que são redundantes por outras verificações em seu fluxo de trabalho?

Há uma observação chamada Lei de Conway, que afirma:

organizações que projetam sistemas ... são constrangidas a produzir projetos que são cópias das estruturas de comunicação dessas organizações.

O que isso tem a ver com solicitações pull? As solicitações pull são um importante canal de comunicação em uma junção crítica para seu código. Eles oferecem uma oportunidade para revisão, teste automatizado e aprimoramento antes que o código avance para os próximos estágios de teste e produção, onde essas mudanças são muito mais difíceis de serem recuperadas e perdem muito mais tempo com muito mais pessoas.

Da mesma forma, a Lei de Conway sugere que se você deseja ter uma arquitetura de microsserviço com áreas de responsabilidade autônoma bem separadas e interfaces bem definidas, os canais de comunicação da sua organização devem refletir a arquitetura que você deseja alcançar. Isso significa que equipes pequenas de 5 a 10 pessoas devem ter acesso direto a qualquer microsserviço, e qualquer pessoa fora dessa equipe deve passar por uma solicitação de recebimento. Isso garante que as pessoas mais familiarizadas com um microsserviço sejam as que analisam e aconselham.

Quando você tem uma organização grande com todos com acesso direto à confirmação em todos os lugares, seus canais de comunicação de menor resistência o preparam para produzir uma grande arquitetura de barro.

Solicitações pull só parecem um fardo se você não trocar nada em troca. Trabalhei em ambientes em que não consigo fazer nada por uma semana porque a compilação está sempre corrompida e trabalhei em ambientes em que alguém envia uma solicitação de recebimento e nem preciso revisá-la porque eles foram interrompidos a criação do IC, e digo-lhe, eles valem cada segundo de esforço.

Karl Bielefeldt está exatamente certo. Eu acrescentaria: é tudo sobre qualidade.

Muitas (a maioria?) Lojas não possuem processos formais para governar o desenvolvimento, o que resulta em: "Trabalhei em ambientes onde não consigo fazer nada por uma semana porque a construção está sempre quebrada e trabalhei em ambientes em que alguém envia uma solicitação de recebimento e eu nem preciso revisá-la porque eles quebraram a compilação do IC, e digo, eles valem cada segundo de esforço ".

Realmente vale o esforço.

Usamos solicitações pull para revisão de código - nenhum código deve ser mesclado no ramo principal de desenvolvimento (normalmente "desenvolva" no nosso caso, mas às vezes "mestre") sem ter passado por uma solicitação pull. Não impomos isso com controles de repositório, mas isso é porque não precisamos - nossos desenvolvedores são maduros o suficiente para não abusar do processo.