Verifica delle conoscenze

Completato

Scegliere la risposta migliore per ogni domanda.

Verificare le conoscenze

1.

Quale non è un buon motivo per creare una richiesta pull?

Si vuole ricevere un feedback sulle modifiche future prima di eseguire il merge del ramo di funzionalità nel ramo main.

Si vuole eseguire il merge del ramo di correzione di bug in main, ma non si ha l'autorizzazione.

Non è possibile eseguire il merge del ramo in main a causa di modifiche upstream apportate dopo la creazione. Creando una richiesta pull un utente fa sapere all'altro collaboratore quando quest'ultimo deve eseguire il pull delle sue modifiche così che l'utente possa inserire a sua volta le sue.

2.

In che modo è possibile garantire che le richieste pull per una determinata area del repository non vengano unite senza l'approvazione di determinati utenti o team?

Spiegare chiaramente i criteri delle richieste pull in CONTRIBUTING.md.

Usare un file CODEOWNERS e abilitare le revisioni obbligatorie.

Aggiungere una tabella che esegue il mapping dei percorsi di directory per gli utenti obbligatori in SECURITY.md.

3.

Si richiede di rivedere una richiesta pull. Durante la lettura, si notano alcuni errori di codifica e di digitazione non gravi. Come è consigliabile gestire la revisione?

Avviare una revisione e correggere gli errori di digitazione evidenti inline. Aggiungere commenti nelle posizioni che richiedono ulteriore discussione o in cui è possibile offrire valore didattico. Completare la revisione con le modifiche richieste.

Lasciare singoli commenti per ogni problema riscontrato, ma non modificare il codice. Per gli errori di digitazione, includere l'ortografia corretta della parola come riferimento. Approvare la richiesta pull se si ritiene che l'autore implementerà i suggerimenti.

Rifiutare la richiesta pull. Non bisogna rischiare il merge accidentale di bug in un ramo importante.

Devi rispondere a tutte le domande prima di controllare il lavoro svolto.