Como criar uma boa solicitação pull

As solicitações de envio são como o sangue de um repositório. Eles mantêm tudo saudável e em movimento. Esta página detalha como criar um PR completo e fácil de analisar, o que aumenta a probabilidade de uma RP ser mesclada.

Aqui estão as etapas que você pode seguir para criar o melhor RP possível.

  1. Comunicação
  2. Configuração
  3. Mantenha o tamanho pequeno
  4. Mantenha a limpeza
  5. Teste sua mudança
  6. Comunicação (pt2)

Comunicação

Antes de começar a escrever código, é útil se comunicar com a equipe principal para que eles saibam seus interesses.

Se houver um problema no qual você esteja interessado, coloque um comentário sobre ele dizendo que você vai começar a trabalhar nele. Isso garante que não haja várias pessoas trabalhando na mesma coisa. Um membro da equipe responderá para confirmar que é seu.

Se você tiver uma ideia que não foi abordada por problema, escreva um antes de começar o trabalho. Isso dá à equipe a chance de discutir a melhor forma de criar a mudança antes de começar a criar, o que economiza seu trabalho a longo prazo.

Começar a configuração

Se esta é sua primeira contribuição com o Blockly ou as amostras em bloco, comece na página de configuração de desenvolvimento.

Mantenha-o pequeno

Tente sempre manter suas mudanças pequenas e focadas. Preferimos analisar vários PRs menores do que analisar um PR gigante. Algumas boas regras de ouro são:

  • Corrigir um problema. Não tente resolver vários problemas de uma vez só.
  • Limitar o escopo. Normalmente, uma RP leva menos de 8 horas, dependendo da sua familiaridade com a base de código.
  • Use confirmações. Se sua RP parece um pouco grande, divida as alterações em grupos lógicos usando confirmações do git.

Mantenha tudo limpo

Por que se importar com o estilo de código? Pensamos no longo prazo, e um estilo consistente facilita a manutenção. Estilo se refere a como você nomeia suas variáveis, mas também abrange como você estrutura o código, escreve comentários e muito mais. Sempre que possível, usamos ferramentas como o eslint para automatizar verificações de estilo.

Além do eslint, siga estes guias:

Teste a mudança

Antes de apresentar um PR, você sempre deve testar se as alterações estão funcionando, para que não precise voltar e corrigir algo mais tarde. Confira algumas ideias para testar as diferentes categorias de projetos:

  • Para plug-ins: escreva testes mocha automatizados que cubram suas mudanças.
  • Exemplos: teste manualmente toda a funcionalidade demonstrada.
  • Para codelabs: siga o tutorial inteiro em um ambiente limpo e teste qualquer exemplo de código fornecido.

Comunicação

Esta é a última e, sem dúvida, a parte mais importante da criação de um PR: escrever o resumo.

Escrever um bom resumo de RP ajuda outros desenvolvedores a revisar suas alterações, aumentando a probabilidade de que elas sejam aceitas mais rapidamente.

Seu resumo deve incluir itens como:

  • A que problema seu PR está relacionado.
  • Que mudança seu RP adiciona.
  • Como você testou a mudança.
  • Tudo que você quer que os revisores examinem.
  • Outras informações que você achar que os revisores precisam.

Se você seguir o modelo de relações públicas ao criar sua solicitação, tudo estará pronto. Lembre-se de ser o mais conciso e completo possível.

Boa programação!