Richieste pull - MRTK2

Prerequisiti

Se in precedenza non hai contribuito a un progetto Microsoft, potrebbe essere richiesto di firmare un contratto di licenza per i contributi. Un commento nella richiesta pull ti informa se lo fai.

Importante

Se si è un dipendente Microsoft e non si è membri dell'organizzazione Microsoft in GitHub, collegare gli account Microsoft e GitHub in corpnet visitando Open Source presso Microsoft prima di avviare la richiesta pull. Ci sono alcune cose di processo che dovrai fare in anticipo.

Creazione di una richiesta pull

Quando si è pronti per inviare una richiesta pull, creare una richiesta pull destinata al ramo principale . Per le correzioni di bug durante un periodo di stabilizzazione del rilascio, cercare il ramo più recente prerelease/* . Le nuove funzionalità devono essere sempre inserite in main.

Leggere le linee guida e assicurarsi che la richiesta pull soddisfi le linee guida.

• Assicurarsi di fare riferimento a qualsiasi richiesta di problema/richiesta di funzionalità o attività a cui è correlata la richiesta pull.
• Controllare che la richiesta pull contenga solo file/modifiche correlati alla richiesta pull.
• Verificare che la documentazione sia aggiornata e inclusa. Controllare che tutti i campi pubblici abbiano commenti.
• Se si aggiunge una nuova funzionalità, verificare che i test siano inclusi per convalidare la funzionalità (vedere UnitTests).
• Se si corregge un bug, scrivere un test per verificare la correzione di bug.

I gestori del progetto esamineranno le modifiche apportate. L'obiettivo è esaminare tutte le modifiche entro tre giorni lavorativi. Si prega di rispondere a eventuali commenti di revisione, push nel ramo dell'argomento e pubblicare un commento che ci informa che ci sono nuove cose da rivedere.

Nota

Tutte le richieste pull inviate al progetto verranno esaminate anche in base alla guida agli standard di codifica MRTK, quindi esaminarli prima di inviare la richiesta pull per garantire un processo uniforme.

Linee guida per le richieste pull

Queste linee guida si basano sulle procedure di progettazione di Google.

Mantenere le richieste pull di piccole dimensioni

Le richieste pull più piccole vengono esaminate più rapidamente e accuratamente, è meno probabile introdurre bug, eseguire più facilmente il rollback e semplificare l'unione.

Le richieste pull devono essere sufficientemente piccole da poter essere esaminate da un tecnico in meno di 30 minuti. Provare a apportare una modifica minima che risolve solo una cosa. Se è necessario creare una richiesta pull di grandi dimensioni, suddividerla in diverse richieste pull che entrano nel ramo locale o in un ramo di funzionalità di MRTK. Evitare di aggiungere nuovi asset (ad esempio fbx, file obj) e mirare invece a riutilizzare gli asset esistenti.

I test devono essere aggiunti nella stessa richiesta pull della correzione/funzionalità, ad eccezione delle emergenze

I test sono il modo migliore per garantire che le modifiche non regrediscano il codice esistente, ma è anche facile dimenticare i test durante l'invio di richieste pull. La richiesta di accesso con la richiesta pull è un ottimo modo per garantire che i test vengano scritti.

A ogni funzionalità e correzione di bug devono essere associati test. Se non si dispone dell'esperienza o del tempo per scrivere un test, creare un problema per scrivere i test e contrassegnarli con l'etichetta Considera per iterazione corrente.

La documentazione deve essere aggiunta nella stessa richiesta pull di una correzione/funzionalità

La maggior parte degli sviluppatori esamina prima la documentazione, non il codice, quando si comprende come usare una funzionalità. Garantire che la documentazione sia aggiornata rende molto più semplice per gli utenti utilizzare e fare affidamento su MRTK. La documentazione deve essere sempre combinata con il pull correlato per garantire che gli elementi rimangano aggiornati e coerenti.

Assicurarsi che ogni campo pubblico, metodo, proprietà abbia commenti di riepilogo a barre triplica , in modo che il sito docfx possa generare descrizioni per campi/metodi. Se necessario, aggiornare i file markdown nella cartella Documentazione.

Le descrizioni delle richieste pull devono descrivere chiaramente e completamente le modifiche

Le descrizioni chiare e complete delle richieste pull assicurano che i revisori comprendano cosa stanno esaminando.

Se si aggiungono funzionalità che contengono l'esperienza utente, aggiungere un'immagine/gif della funzionalità che si sta modificando. Ecco un buon esempio. Un altro suggerimento consiste nell'avere una gif di Before e After, ad esempio in questa richiesta pull. Uno strumento consigliato per la generazione di gif dalle acquisizioni dello schermo è ScreenToGif.