Git offre strategie di ramificazione flessibili, ma cosa significa? In parole semplici, una strategia di ramificazione è un insieme di regole, una convenzione che aiuta team e sviluppatori:possono seguire queste regole e convenzioni per creare un nuovo ramo, il suo flusso, ecc.
Il mancato utilizzo di convenzioni di denominazione appropriate crea confusione e complica il team di manutenzione del codice. Non possiamo ignorare le best practice di Git nelle convenzioni di denominazione ramificate.
Le strategie di ramificazione Git consentono la separazione del lavoro. In generale, possiamo dividere i rami Git in due categorie:rami regolari e temporanei.
Rami Git regolari
Questi rami saranno disponibili nel tuo repository su basi permanenti. La loro convenzione di denominazione è semplice e diretta.
- Sviluppo (sviluppo ) è il principale ramo di sviluppo. L'idea del ramo di sviluppo è di apportare modifiche e impedire agli sviluppatori di apportare modifiche direttamente al ramo principale. Le modifiche nel ramo dev sono sottoposte a revisione e, dopo il test, vengono unite al ramo master.
- Maestro (maestro ) è il ramo predefinito disponibile nel repository Git. Dovrebbe essere sempre stabile e non consentirà alcun check-in diretto. Puoi unirlo solo dopo la revisione del codice. Tutti i membri del team sono responsabili di mantenere il master stabile e aggiornato.
- QA (QA ), o test branch, contiene tutto il codice per il test QA e il test di automazione di tutte le modifiche implementate. Prima che qualsiasi modifica venga apportata all'ambiente di produzione, deve essere sottoposto al test di controllo qualità per ottenere una base di codice stabile.
Rami Git temporanei
Come indica il nome, questi sono i rami che possono essere creati ed eliminati quando necessario. Possono essere i seguenti:
- Correzione di bug
- Correzione rapida
- Rami di funzionalità
- Rami sperimentali
- filiali WIP
Esistono molti formati e convenzioni di denominazione consigliati dagli esperti per le filiali temporanee.
Ecco un semplice flusso di lavoro dei rami Git.
Convenzione di denominazione del ramo Git
In questo articolo esaminerò e condividerò le sette migliori convenzioni di denominazione che ho utilizzato personalmente in passato per garantirne l'efficienza.
1. Inizia il nome del ramo con una parola di gruppo
È una delle migliori pratiche. La parola di gruppo può essere qualsiasi cosa che corrisponda al tuo flusso di lavoro.
Mi piacciono le parole brevi come le seguenti:
Blocco – Il bug che deve essere corretto a breve
WIP – Il lavoro è in corso e sono consapevole che non finirà presto
Osservando il nome del ramo, puoi capire di cosa tratta questo ramo Git e il suo scopo.
Dai un'occhiata agli esempi seguenti:
- bug-logo-alignment-issue:lo sviluppatore sta cercando di risolvere il problema di allineamento del logo;
- wip-ioc-container-added:il ramo si riferisce all'attività di aggiunta di un container IoC in corso.
2. Usa l'ID univoco nei nomi delle filiali
Puoi utilizzare l'ID del tracker dei problemi nel nome della tua filiale. Preferisco questo metodo quando lavoro per correggere alcuni bug. Ad esempio:
wip-8712-add-testing-module
Il nome indica che il ramo si applica all'attività di aggiunta di un modulo di test, l'ID di tracciamento del problema è 8712 e il lavoro è in corso.
Un altro vantaggio dell'utilizzo di un ID di tracciamento esterno nel nome della filiale è la possibilità di tracciare lo stato di avanzamento da un sistema esterno.
3. Usa trattino o barra come separatori
Molti sviluppatori usano la barra come separatore e molti usano i trattini. Quale usare:dipende da te e dalle preferenze del tuo team.
La mia opinione è che i trattini rendano il nome più comodo da leggere, quindi è un separatore adatto nei nomi dei rami. È possibile utilizzare barre, trattini e trattini bassi. Il punto è essere coerenti.
Ci sono due vantaggi principali nell'usare un separatore nel nome del ramo:
- Aumenta la leggibilità e aiuta a evitare confusione;
- Semplifica la gestione, soprattutto se hai a che fare con molte filiali.
Esempio 1. Nome del ramo Git senza alcun separatore:
featureupgradejqueryversionloginmodule
Esempio 2. Aggiungendo un separatore (in questo caso è un trattino basso), rendi leggibile il nome del ramo Git:
feature_upgrade_jquery_version_login_module
4. Git Branch con il nome dell'autore
Molte aziende preferiscono aggiungere i nomi degli autori nei nomi delle filiali secondo il formato seguente:
<author>_<branch-type>_<branch-name>Ad esempio, rajeev.bera_feature_new-experimental-changes
Questo metodo consente di monitorare facilmente il lavoro e i progressi di diversi sviluppatori con sistemi aggiuntivi.
5. Evita di usare solo numeri
Alcuni sviluppatori utilizzano solo l'ID problema nel nome del ramo, che non è utile nell'avanzamento del lavoro.
Ad esempio, c'è un nome di ramo 9912:cosa dovrebbe dirci questo numero magico? Significa solo più confusione e rischio di errori, specialmente durante l'unione con altri rami git.
6. Evita di utilizzare tutte le convenzioni di denominazione contemporaneamente
Mescolare e abbinare tutte le convenzioni di denominazione dei rami Git non è la migliore pratica. Aggiunge solo confusione e complica i processi generali.
Un team dovrebbe decidere le convenzioni di denominazione da utilizzare al lavoro una volta e attenersi ad esse. La coerenza è la cosa più critica.
7. Evita nomi descrittivi lunghi per rami longevi
La qualità essenziale del nome di una filiale è che dovrebbe essere preciso e informativo. Diamo di nuovo un'occhiata ad alcuni esempi:
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
Lì, i nomi dei rami sono lunghi e dettagliati. Non è necessario. Invece, potresti usare la seguente variante:
wip_feature_login_module
Questo nome è breve, ma spiega lo scopo di questo ramo.
Conclusione
Il modello di ramificazione Git è potente, ma è necessario gestire i rami in modo corretto ed efficace. Uno dei fattori necessari è seguire le stesse convenzioni da parte di tutti i team, in particolare le convenzioni di denominazione per il repository locale.
Per assicurarti che il tuo team utilizzi le convenzioni concordate, applica gli standard. Uno dei modi più semplici è usare gli hook Git, come l'hook pre-commit. Spero che ti dia un'idea sui modelli di ramificazione Git e sulla loro convenzione di denominazione.
