Componenti del flusso GitHub

Completato

In questa unità vengono esaminati i componenti seguenti del flusso GitHub:

• Rami
• Commit
• Richieste pull
• Flusso di GitHub

Che cosa sono i rami

Nell'ultima sezione è stato creato un nuovo file e un nuovo ramo nei repository.

I rami sono una parte essenziale dell'esperienza GitHub perché è possibile apportare modifiche senza influire sull'intero progetto su cui stiamo lavorando.

Il ramo è un luogo sicuro per sperimentare nuove funzionalità o correzioni. Se si commette un errore, è possibile ripristinare le modifiche o eseguire il push di altre modifiche per correggere l'errore. Le modifiche non verranno aggiornate nel ramo predefinito fino a quando non si unisce il ramo.

Nota

In alternativa, è possibile creare un nuovo ramo ed estrarlo usando Git in un terminale. Il comando sarà git checkout -b newBranchName

Che cosa sono i commit

Nell'unità precedente è stato aggiunto un nuovo file nel repository eseguendo il push di un commit. Esaminiamo brevemente i commit.

Un commit è una modifica apportata a uno o più file di un ramo. Ogni volta che viene creato un commit, gli viene assegnato un ID univoco e viene monitorato insieme alla data e al collaboratore. I commit forniscono un audit trail chiaro per chiunque esami la cronologia di un file o di un elemento collegato, ad esempio un problema o una richiesta pull.

All'interno di un repository Git un file può esistere in diversi stati validi durante il processo di controllo della versione. Gli stati principali per un file in un repository Git sono Untracked e Tracked.

Untracked: Stato iniziale di un file quando non fa ancora parte del repository Git. Git non è a conoscenza della sua esistenza.

Tracked: Un file rilevato è un file monitorato attivamente da Git. Può trovarsi in uno degli stati secondari seguenti:

• Unmodified: Il file viene rilevato, ma non è stato modificato dall'ultimo commit.
• Modified: Il file è stato modificato dopo l'ultimo commit, ma queste modifiche non vengono ancora predisposte per il commit successivo.
• Staged: Il file è stato modificato e le modifiche sono state aggiunte all'area di gestione temporanea (nota anche come indice). Queste modifiche sono pronte per il commit.
• Committed: Il file si trova nel database del repository. Rappresenta la versione di cui è stato eseguito il commit più recente del file.

Questi stati e sottostati sono importanti per collaborare con il team e sapere dove si trova ogni singolo commit nel processo del progetto. A questo punto si passerà alle richieste pull.

Che cosa sono le richieste pull?

La richiesta pull è il meccanismo usato per segnalare che i commit di un ramo sono pronti per essere uniti a un altro ramo.

Il membro del team che invia la richiesta pull chiede a uno o più revisori di verificare il codice e approvare il merge. Questi revisori hanno la possibilità di commentare le modifiche, aggiungerne di proprie o usare la richiesta pull per ulteriori discussioni.

Dopo l'approvazione delle modifiche (se richiesta), viene eseguito il merge del ramo di origine della richiesta pull (ramo di confronto) con il ramo di base.

Ora che sappiamo tutti gli ingredienti, esaminiamo il flusso di GitHub.

Flusso di GitHub

Il flusso GitHub può essere definito come un flusso di lavoro leggero che consente la sperimentazione sicura. È possibile testare nuove idee e collaborazione con il team usando la diramazione, le richieste pull e l'unione.

Ora che si conoscono le nozioni di base di GitHub, è possibile esaminare il flusso di GitHub e i relativi componenti.

1. Per iniziare, creare un ramo in modo che le modifiche, le funzionalità e le correzioni create non influiscano sul ramo principale.
2. Apportare quindi le modifiche. È consigliabile distribuire le modifiche al ramo di funzionalità prima di eseguire l'unione nel ramo principale. In questo modo si garantisce che le modifiche siano valide in un ambiente di produzione.
3. A questo punto, creare una richiesta pull per chiedere feedback ai collaboratori. La revisione delle richieste pull è così utile che alcuni repository richiedono una revisione di approvazione prima che le richieste pull possano essere unite.
4. Esaminare e implementare quindi il feedback dei collaboratori.
5. Quando si è soddisfatti delle modifiche, è possibile ottenere l'approvazione della richiesta pull e unirla al ramo principale.
6. Infine, è possibile eliminare il ramo. L'eliminazione del ramo segnala che il lavoro nel ramo è stato completato e impedisce all'utente o ad altri di usare accidentalmente i rami precedenti.

Questo è il ciclo di flusso di GitHub.

Si passerà ora alla sezione successiva in cui verranno illustrate le differenze tra problemi e discussioni.