Esercizio - Creare la prima richiesta pull

  • 6 minuti

Si è appreso come creare una richiesta pull in base alle line guida disponibili, ad esempio, in un modello di richiesta pull o in un file CONTRIBUTING. Come si deve invece procedere se un progetto non include tali indicazioni e la documentazione sulle convenzioni?

Descrivere le modifiche

Per scrivere un messaggio di commit valido e successivamente la richiesta pull, seguire questa procedura:

  • La riga dell'oggetto del messaggio di commit di Git dovrebbe contenere la frase seguente:
    • Se applicato, il commit sarà <your subject line here>.
  • Includere una breve descrizione della modifica usando l'imperativo presente. Usare, ad esempio, add, non added o adds.
  • Non immettere più di 50 caratteri nella riga dell'oggetto.
  • Iniziare con una lettera maiuscola e non terminare con un punto (.).
  • È possibile usare emoji o @mention altri utenti di GitHub nella riga dell'oggetto, ma tenere presente che non tutti i progetti consentono o incoraggiano questa operazione.

Nel corpo del messaggio e nella richiesta pull continuare a usare il tempo presente. Assicurarsi di includere la motivazione della modifica. Confrontare la modifica con il comportamento precedente. Usare lo spazio a disposizione per spiegare che cosa e perché più che come.

Il messaggio di commit è importante quanto il contenuto che si intende inviare. Eseguire il commit o l'invio per la revisione di piccoli set isolati di modifiche. Questa prassi aumenta le probabilità che le modifiche vengano unite nel progetto.

Aggiungere granularità

Prima di inviare la richiesta pull, controllare nella barra laterale come è possibile completare la richiesta pull. Selezionare Reviewers (Revisori) o Assignees (Assegnatari) se si ha familiarità con la struttura del team del progetto. Aggiungere le etichette quando sono presenti indicazioni su come usarle, ad esempio nel file CONTRIBUTING.md. È possibile usare le etichette come indicazioni visive di ciò che si intende fare. Anche un gestore potrebbe aggiungere una o più etichette.

Suggerimento

Se nel repository è presente un file CONTRIBUTING.md o un modello di richiesta pull, seguire le indicazioni fornite durante la compilazione della richiesta pull.

Alcune delle etichette usate nel repository per questo modulo di Learn sono:

  • Bug (rosso): qualcosa non funziona
  • Documentazione (blu): miglioramenti o aggiunte alla documentazione
  • Duplicato (grigio): questo problema o richiesta pull esiste già
  • Miglioramento (verde acqua): nuova funzionalità o richiesta

Facoltativamente è possibile collegare i problemi nella barra laterale, dove il merge di una richiesta pull potrebbe chiudere il problema corrispondente. È anche possibile personalizzare la sottoscrizione delle notifiche nel thread. Alcune richieste pull ricevono molti commenti, revisioni e notifiche relative a CI/CD. È possibile scegliere tra:

  • Non sottoscritto: per ricevere le notifiche solo quando si è partecipato o si è stati menzionati tramite @mentioned
  • Sottoscritto: per ricevere tutte le notifiche per questa richiesta pull
  • Personalizzate: per ricevere le notifiche solo per gli eventi selezionati

Esercizio

Usando il progetto First Contributions, esercitarsi nel fork, nella clonazione e nell'invio di una richiesta pull. Il progetto First Contributions vuole essere una "guida per i principianti sulla creazione del primo contributo". Offre indicazioni sull'uso della riga di comando e di diverse interfacce utente grafiche (GUI). Il progetto supporta anche diverse lingue. Assicurarsi di controllare il contenuto della cartella Translations.

Tenendo presente quanto è stato spiegato in questa unità e in quella precedente, tornare a una richiesta pull aperta di recente. In alternativa, è possibile passare alla scheda delle richieste pull di un progetto in esame. Si noti come una riga dell'oggetto ben scritta possa fare la differenza. Valutare l'opportunità di aggiornare una richiesta pull di conseguenza. Dedicare alla scrittura della richiesta pull all'incirca lo stesso tempo impiegato per apportare la modifica al progetto. L'impegno profuso consentirà ai gestori di suddividere in categorie e di classificare in ordine di priorità (valutare) i contributi della community.

Suggerimento: controllare le linee guida e i requisiti di Microsoft per l'accessibilità. Vedere in particolare le informazioni sulla descrizione delle interazioni con l'interfaccia utente per evitare di usare termini troppo specifici. I clienti interagiscono con i prodotti usando metodi di input diversi. Ad esempio, possono usare la tastiera, il mouse, il tocco, la voce e altri ancora. È consigliabile usare verbi generici che si applicano a qualsiasi metodo di input. Usare, ad esempio, select (selezionare) invece di click (fare clic) o swipe (scorrere), che sono specifici del tipo di input.