Componenti del flusso GitHub

Completato

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

• Rami
• Commit
• Richieste pull
• Flusso di GitHub
• Flusso Git

Componenti di GitHub Flow

Prima di accedere ai flussi di lavoro specifici di GitHub, è utile comprendere che GitHub Flow si basa direttamente sui concetti fondamentali di Git.

Git offre strumenti per tenere traccia e gestire le modifiche nel codice nel tempo. GitHub si basa su questo aspetto semplificando l'uso di questi strumenti con funzionalità come rami, commit, richieste pull e interfacce visive per la collaborazione. Si inizierà esaminando il funzionamento di questi concetti in GitHub.

Che cosa sono i rami

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

I rami sono una parte essenziale dell'esperienza GitHub. Consentono di apportare modifiche senza influire sul ramo predefinito.

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 commit viene rilevato da un ID, un timestamp e un collaboratore univoci, indipendentemente dal fatto che venga eseguito tramite la riga di comando o direttamente nell'interfaccia Web di GitHub. 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.

È possibile creare un commit usando Git nel terminale con:

git commit -m "Add a helpful commit message"

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 aiutano il team a comprendere lo stato di ogni file e dove si trova nel processo di controllo della versione.

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.

GitHub supporta anche le richieste pull bozza, che consentono di aprire una richiesta pull non ancora pronta per la revisione.

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 si è visto come funzionano rami, commit e richieste pull, è possibile esaminare come interagiscono in GitHub Flow.

Flusso di GitHub

Il flusso di GitHub è un flusso di lavoro semplice che consente di apportare e condividere le modifiche in modo sicuro. È ideale per provare idee e collaborare con il team usando rami, richieste pull e merge.

Nota

Il flusso di GitHub è uno dei diversi flussi di lavoro più diffusi. Altri includono il flusso Git e lo sviluppo basato su trunk.

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à o le correzioni non influiscano sul ramo principale.
2. Eseguire quindi gli aggiornamenti nel ramo . Se il flusso di lavoro lo supporta, è possibile distribuire le modifiche da questo ramo per testarle prima dell'unione.
3. A questo punto, aprire una richiesta pull per invitare commenti e suggerimenti e iniziare una revisione.
4. Esaminare quindi i commenti e apportare eventuali aggiornamenti necessari in base al feedback del team.
5. Infine, quando si è certi delle modifiche, ottenere l'approvazione e unire la richiesta pull nel ramo principale.
6. Successivamente, eliminare il ramo per mantenere pulito il repository ed evitare l'uso di rami obsoleti.

Flusso Git

Anche se GitHub Flow è un flusso di lavoro leggero progettato per il recapito continuo, Il flusso Git è un modello di diramazione più strutturato spesso usato negli ambienti basati sul rilascio. Il flusso Git è stato intorno a più tempo rispetto a GitHub Flow ed è comunque possibile visualizzare il termine master usato anziché main come ramo predefinito.

Tipi di ramo di flusso Git

Il flusso Git usa diversi rami temporanei e di lunga durata:

• master: riflette sempre il codice pronto per la produzione.
• develop: contiene il lavoro di sviluppo più recente per la versione successiva.
• feature/*: usato per creare nuove funzionalità; diramati da develop e uniti al termine.
• release/*: prepara una nuova versione di produzione da develop; consente test finali e correzioni di bug secondarie.
• hotfix/*: usato per applicare rapidamente patch ai problemi di produzione; rami da master.

Funzionamento del processo di flusso Git

1. Gli sviluppatori creano rami di funzionalità da develop per creare nuove funzionalità.
2. Quando è il momento di una versione, viene creato un ramo di versione da develop. Questo isola il lavoro di preparazione del rilascio in modo che lo sviluppo possa continuare senza interruzioni.
3. È possibile aggiungere correzioni di bug al ramo di rilascio, ma le funzionalità principali dovrebbero attendere una versione futura.
4. Una volta pronto, il ramo di rilascio viene unito a master e contrassegnato con un numero di versione. GitHub può usare questi tag per generare note sulla versione.
5. Lo stesso ramo di rilascio deve essere unito di nuovo in develop per mantenerlo sincronizzato.
6. Se si verifica un bug di produzione critico, viene creato un ramo hotfix da master. Una volta corretto, viene unito sia in che developin master .

Quando usare il flusso Git

• Ideale per i progetti con versioni pianificate o con versioni
• Utile se si mantengono più versioni di produzione (ad esempio, rami di supporto a lungo termine)
• Ideale per cicli di sviluppo più lenti e strutturati (ad esempio, ambienti aziendali o regolamentati)
• Considerato più "pesante" rispetto a GitHub Flow a causa di una gestione aggiuntiva dei rami

Nota

Il flusso Git presuppone commit di merge per l'integrazione dei rami. L'uso di rebase o merge di squash può interferire con la struttura dei rami e il rilevamento della cronologia.

Per molti team che usano GitHub, GitHub Flow è più semplice e veloce. Tuttavia, se i valori del team sono prevedibili e hanno bisogno di una pianificazione del rilascio maggiore, il flusso Git potrebbe essere più adatto.

Congratulazioni! Si è appena esaminato il flusso GitHub completo ed è stato esaminato il modo in cui il flusso Git offre un'alternativa strutturata per i progetti basati sul rilascio.

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