Pedidos Pull

Pré-requisitos

Se ainda não contribuiu para um projeto da Microsoft, pode ser-lhe pedido que assine um contrato de licença de contribuição. Um comentário no Pr informá-lo-á se o fizer.

Importante

Se é funcionário da Microsoft e não é membro da organização da Microsoft na GitHub, por favor ligue as suas contas microsoft e GitHub à corpnet visitando o Open Source na Microsoft antes de iniciar o seu pedido de pull. Há algumas coisas de processo que terás de fazer antes do tempo.

Criar um pedido Pull

Quando estiver pronto para apresentar um pedido de retirada, crie um pedido de atração dirigido ao ramo principal. Para correções de insetos durante um período de estabilização de libertação, procure o ramo mais prerelease/* recente. As novas funcionalidades devem sempre entrar main em .

Leia as diretrizes e certifique-se de que o seu pedido de puxar cumpre as diretrizes.

  • Certifique-se de que faz referência a qualquer Problema / Pedido de Recurso ou Tarefa a que o PR se relacione.
  • Verifique o pedido de puxar contém apenas ficheiros/alterações relacionadas com o PR.
  • Verifique se a documentação está atualizada e incluída. Verifique todos os campos públicos com comentários.
  • Se adicionar uma nova funcionalidade, verifique se os testes estão incluídos para validar a funcionalidade (ver UnitTests).
  • Se consertar um erro, escreva um teste para verificar a correção do erro.

Os defensores do projeto irão rever as suas alterações. Pretendemos rever todas as alterações no prazo de três dias úteis. Por favor, dirija-se a quaisquer comentários de revisão, empurre para o seu ramo tópico, e publique um comentário informando-nos que há coisas novas para rever.

Nota

Todas as relações públicas submetidas ao projeto também serão examinadas de acordo com o guia de normas de codificação MRTK,por isso, por favor, reveja-as antes de submeter o seu Pr para garantir um processo suave.

Puxe as diretrizes de pedido

Estas diretrizes baseiam-se nas práticas de engenharia da Google.

Mantenha os pedidos de puxar pequenos

Os PRs mais pequenos são revistos de forma mais rápida e minuciosa, são menos propensos a introduzir bugs, mais fáceis de retrocessar e mais fáceis de fundir.

Os pedidos de puxar devem ser pequenos o suficiente para que um engenheiro possa revê-lo em menos de 30 minutos. Tente fazer uma mudança mínima que aborde apenas uma coisa. Se tiver de criar um grande pr, divida-o em vários PRs que vão para a sua filial local, ou um ramo de recurso de MRTK. Evite adicionar novos ativos (por exemplo, ficheiros fbx, obj) e, em vez disso, procure reutilizar os ativos existentes.

Os testes devem ser adicionados no mesmo PR que a sua correção/funcionalidade, exceto para emergências

Os testes são a melhor forma de garantir que as alterações não regredirem o código existente, mas também é fácil esquecer os testes ao apresentar pedidos de pull. Exigir que eles entrem com o seu RP é uma ótima maneira de garantir que os testes sejam escritos.

Todas as funcionalidades e correções de bugs devem ter testes associados. Se não tiver a experiência ou tempo para escrever um teste, crie um problema para escrever os testes e marque-os com a etiqueta Consider for Current Iteration.

A documentação deve ser adicionada no mesmo pedido de puxar que uma correção/funcionalidade

A maioria dos desenvolvedores olha primeiro para a documentação, não para o código, ao entender como usar uma funcionalidade. Garantir que a documentação está atualizada torna muito mais fácil para as pessoas consumirem e confiarem no MRTK. A documentação deve ser sempre agregada com a atração relacionada para garantir que os itens permanecem atualizados e consistentes.

Certifique-se de que todos os campos públicos, métodos, propriedade têm comentários sumários triplos para que o nosso site docfx possa gerar descrições para campos/métodos. Se necessário, atualize ficheiros de marcação na pasta de documentação.

As descrições do pedido de puxar devem descrever de forma clara e completa as alterações

Descrições claras e completas dos pedidos de pull garantem que os revisores entendem o que estão a rever.

Se adicionar funcionalidades que contenham UX, adicione uma imagem/gif da funcionalidade que está a mudar. Aqui está um bom exemplo. Outra sugestão é ter um gif de Antes e Depois, por exemplo neste pedido de puxar. Uma ferramenta que recomendamos para gerar gifs a partir de capturas de ecrã é o ScreenToGif.