Git - Quali problemi sorgono lavorando direttamente sul master?

Ho visto molti consigli sui modelli di ramificazione git e l'opinione più comune sembra essere che apportare modifiche direttamente sul ramo master sia una cattiva idea.

Uno dei nostri collaboratori è abbastanza contento di apportare modifiche direttamente al ramo principale e, nonostante diverse conversazioni, sembra che non lo cambino.

A questo punto, non riesco a convincere un collega che è una cattiva pratica a lavorare direttamente sul maestro, ma vorrei capire le cose che entreranno in conflitto con il suo modo di lavorare, per sapere quando devo rivisitare questa edizione.

Esistono diversi problemi quando i commit vengono inviati direttamente al master

• Se si sposta uno stato di avanzamento lavori su remoto, il master è potenzialmente guasto
• Se un altro sviluppatore inizia a lavorare per una nuova funzionalità dal master, inizia con uno stato potenzialmente interrotto. Questo rallenta lo sviluppo
• Diverse funzionalità / correzioni di bug non sono isolate, in modo che la complessità di tutte le attività di sviluppo in corso sia combinata in un ramo. Ciò aumenta la quantità di comunicazione necessaria tra tutti gli sviluppatori
• Non puoi fare richieste pull che sono un ottimo meccanismo per le revisioni del codice
• Non è possibile eseguire lo squash di commit / modificare la cronologia di git in generale, poiché nel frattempo altri sviluppatori potrebbero aver già estratto il ramo principale

Spiegagli che le nuove funzionalità necessitano di un proprio ramo di sviluppo che può essere distribuito in un ambiente di test prima che venga portato alla produzione.

Altrimenti, sei in uno stato perpetuo di funzionalità completate a metà. Non è possibile distribuire funzionalità completate a metà alla produzione, quindi se si lavora direttamente nel ramo principale, tutti gli altri devono attendere che l'utente completi la funzione prima che le modifiche apportate da altri possano passare alla produzione, comprese le correzioni di bug.

L'uso di filiali indipendenti per le funzionalità significa che ogni nuova funzionalità può essere testata e distribuita indipendentemente dalle altre.

Il master dovrebbe essere potenzialmente rilasciabile. Periodo. Non ci dovrebbe essere alcun lavoro a metà finito nel master (a meno che non sia disabilitato con un flag di funzione)

Detto questo, ho visto alcune squadre complicare il loro flusso.

Non usare PR quando si integra con master è un errore poiché gli sviluppatori non avranno il potere di scegliere quando si verifica l'integrazione.

Un singolo ramo di sviluppo porta pochissimo valore. Di solito complica solo le cose. Molti rami di funzionalità apportano molto valore.

Fare rami per ogni ambiente (sviluppo, test, prod) è un errore. Questo non rientra nell'ambito di applicazione di Git e dovrebbe essere gestito dalla pipeline di rilascio. La stessa identica build dovrebbe essere distribuita in tutti gli ambienti, il che è impossibile se ci sono rami per ogni ambiente.

Se una funzionalità è così grande da non poter essere eseguita in un giorno o due, tutto il lavoro su un ramo di funzionalità dovrebbe essere in rami separati e integrato con PR.

• Il master dovrebbe riflettere un ramo di produzione, una versione finale funzionante.
• Lavorare direttamente in master significa che se si creano bug non si ha altra opzione per "tornare indietro" che per annullare / cancellare / ripristinare i commit, il che non è un modo pulito di lavorare e può farti perdere le parti del nuovo codice che erano OK.
• Naturalmente, nelle primissime fasi di sviluppo forse puoi iniziare a lavorare direttamente su master, ma dopo che hai qualcosa da offrire, dovresti usare i rami di sviluppo, test o esperimento per non toccare la versione pubblicata, completa e funzionante.

In primo luogo, voglio sottolineare che in git, ogni cosa pullè letteralmente un'operazione di ramificazione e ogni pushè una fusione. La macchina masteron di uno sviluppatore è un ramo completamente separato da masterun repository centrale che condividi, con una posizione uguale dal punto di vista tecnico. Occasionalmente rinominerò la mia versione locale upstreamo qualcosa del genere se si adatta meglio ai miei scopi.

Lo sottolineo perché molte organizzazioni pensano di utilizzare le filiali in modo più efficace rispetto al tuo collega, quando in realtà stanno facendo poco più che creare un nome aggiuntivo per una filiale lungo la strada, che non verrà comunque salvato nella cronologia. Se il tuo collega sta eseguendo il commit di funzionalità in un commit atomico, è altrettanto facile eseguire il backout come un commit di unione di un ramo di feature. La stragrande maggioranza dei rami delle funzioni dovrebbe essere di breve durata e spesso unita comunque.

Detto questo, i principali svantaggi del suo stile di lavoro sono duplici. Innanzitutto, è molto difficile collaborare a una funzione incompiuta. Tuttavia, non sarebbe difficile creare una succursale proprio in quei momenti in cui è necessaria la collaborazione.

In secondo luogo, rende molto difficile la revisione prima della fusione. Su questo punto, in realtà non è necessario convincerlo. È possibile adottare uno strumento come github, gerrit o gitlab e richiedere revisioni del codice di richiesta pull e superato test automatici per tutte le fusioni. Se non stai facendo qualcosa del genere, francamente non stai usando git per il suo pieno potenziale, e non c'è da meravigliarsi se il tuo collega non vede quel potenziale.

Altre risposte hanno già menzionato vari vantaggi (funzioni isolate, codice sempre disponibile sul master, ecc.) Per lavorare NON direttamente sul master.

Per me sembra che tu abbia un problema diverso. Ovviamente non hai un processo di sviluppo, che è concordato o utilizzato da tutti i tuoi sviluppatori (o il tuo sviluppatore in questione sta totalmente ignorando il processo).

Hai rami delle caratteristiche, che sono uniti in master o hai anche rami di versioni differenti o usi un processo totalmente diverso?

"Non utilizzare il ramo principale" non è sufficiente.

Uno dei nostri collaboratori è abbastanza contento di apportare modifiche direttamente al ramo principale e, nonostante diverse conversazioni, sembra che non lo cambino.

Questo mi porta a credere che ci siano più problemi. Lavorare su master o no fa principalmente parte di una filosofia più ampia su come, cosa e quando si rilasciano prodotti.

Quindi, in combinazione con un "non dovresti mai lavorare sul master", hai test di funzionalità, ti collaudi a vicenda, riesci a rivedere a vicenda il codice? Test di accettazione e integrazione.

Se non hai nessuno dei precedenti e lo stai facendo solo per "fare git", potresti anche lavorare su master.

Non ci sono "cattive pratiche" nel lavorare direttamente sul ramo. Ma devi decidere cosa supporta meglio il tuo processo:

Domanda 1: il tuo master dovrebbe rappresentare lo stato di rilascio attuale del tuo software? Quindi è necessario introdurre un ramo di sviluppo globale e unire lo sviluppo alla fine di uno sviluppo di rilascio.

Domanda 2: vuoi avere un processo di revisione del codice? Quindi dovresti avere "rami delle caratteristiche" che verranno uniti in master (o sviluppati, se ne hai uno) tramite richieste pull.

Domanda 3: è necessario condividere lo stato del codice intermedio con altri sviluppatori che non dovrebbero ancora essere pubblicati in produzione (o test)? Questo è il caso in cui più di uno sviluppatore sviluppa una funzionalità. Quindi dovresti introdurre "rami delle caratteristiche".