Esplorare il flusso di GitHub

  • 2 minuti

Il flusso di GitHub illustra come GitHub può aggiungere valore allo sviluppo tradizionale di software collaborativo basato su Git. Lo scopo è semplificare gli aggiornamenti ai progetti ospitati in GitHub fornendo indicazioni prescrittive sul processo di applicazione delle modifiche al repository del progetto. L'organizzazione nello scenario di esempio trarrà probabilmente vantaggio dall'incorporamento di GitHub Flow nelle procedure DevOps, in particolare considerando la mancanza di esperienza nell'uso di repository basati su Git. In questa unità esaminare la sequenza di passaggi che rappresentano il caso d'uso più comune del flusso GitHub.

Seguire il flusso di GitHub

Diagramma che mostra un flusso di lavoro di ramo di base.

Il flusso di GitHub è costituito dai passaggi seguenti:

  1. Creazione di un repository. Per seguire il flusso di GitHub, sono necessari un account GitHub e un repository. Per impostazione predefinita, un nuovo repository include il ramo predefinito, in genere denominato main.

  2. Creazione di un ramo. La creazione di un altro ramo consente di sviluppare e salvare le modifiche senza influire sul ramo predefinito. Inoltre, consente ad altri utenti di collaborare alle modifiche esaminandoli prima di essere uniti nel ramo principale. È possibile creare un ramo direttamente in GitHub o clonare il repository nel computer locale e creare un ramo.

  3. Apportare modifiche al ramo. Applicare le modifiche al ramo appena creato richiamando le azioni di commit e, se si lavora localmente, di push. È possibile modificare i file direttamente nel repository ospitato in GitHub usando l'interfaccia Web di GitHub. Per ogni commit, fornire un breve messaggio che descrive le modifiche applicate. Ripetere questi passaggi fino a quando non si considerano le modifiche completate e si è pronti a chiedere ad altri utenti di esaminarle.

  4. Creazione di una richiesta pull. Richiedere feedback creando una pull request (comunemente abbreviata come PR) dopo l'ultimo commit sulla branca che hai creato. Fornire un riepilogo delle modifiche incluse nel ramo e spiegare il miglioramento che si intende apportare. Utilizzare la notazione @ per menzionare se si desidera richiedere una revisione da parte di individui o team specifici.

    Diagramma che mostra i rami principali e di funzionalità e una richiesta pull.

  5. Revisione della richiesta pull. Questo è il momento in cui altri utenti intervengono, esaminano la tua richiesta di pull e inviano i loro feedback, tra cui commenti, domande e suggerimenti.

  6. Risposta ai commenti di revisione Al termine delle revisioni, apporta le modifiche necessarie per tenerle in considerazione e attendi l'approvazione del pull request.

  7. Unione della richiesta pull. L'approvazione della richiesta pull consente di unire il contenuto del ramo creato con il ramo predefinito (main). GitHub per impostazione predefinita mantiene i commenti e i commit nella richiesta pull, che consente ad altri utenti di rivederli in qualsiasi momento. Quando si implementa la protezione dei rami, le restrizioni potrebbero influire sulla possibilità di eseguire il merge, quindi assicurarsi prima di tutto che siano soddisfatte.

  8. Eliminazione del ramo. Al termine dell'unione, è possibile eliminare il ramo creato. In questo modo è possibile ridurre al minimo le dimensioni del repository e impedire l'uso accidentale di rami non aggiornati.