Git - Quali problemi nascono dal lavorare direttamente sul master?

Ci sono diversi problemi quando i commit vengono inseriti direttamente nel master

• Se si esegue il push di uno stato di work-in-progress a remoto, il master è potenzialmente danneggiato
• Se un altro sviluppatore inizia a lavorare per una nuova funzione da master, inizia con uno stato potenzialmente danneggiato. 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 eseguire richieste pull che sono un ottimo meccanismo per le revisioni del codice
• Non puoi schiacciare i commit / cambiare la cronologia git in generale, poiché altri sviluppatori potrebbero aver già estratto il ramo principale nel frattempo

Spiegagli che nuove funzionalità hanno bisogno del proprio ramo di sviluppo che può essere distribuito in un ambiente di test prima di essere trasferito alla produzione.

Altrimenti, sei in uno stato perpetuo di funzioni completate a metà. Non è possibile distribuire funzionalità parzialmente completate alla produzione, quindi se lavori direttamente sul ramo principale, tutti gli altri devono aspettare che tu finisca la tua funzione prima che le modifiche di qualcun altro possano andare in produzione, comprese correzioni di errori.

L'utilizzo di rami indipendenti per funzionalità significa che ogni nuova funzione può essere testata e implementata indipendentemente dalle altre.

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

Detto ciò ho notato che alcune squadre complicano il loro flusso.

Non usare PR quando l'integrazione con il master è un errore dato che gli sviluppatori non hanno il potere di scegliere quando avviene l'integrazione.

Un singolo ramo di sviluppo porta pochissimo valore. Di solito complica le cose. Molte funzioni offrono molto valore.

Creare filiali per ogni ambiente (dev, test, prod) è un errore. Questo è fuori portata per git e dovrebbe essere gestito dalla pipeline di rilascio. La stessa build esatta dovrebbe essere distribuita in tutti gli ambienti, cosa impossibile se ci sono rami per ogni ambiente.

Se una funzionalità è così grande che non può 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 crei bug non hai altra opzione per "tornare indietro" che annullare / cancellare / resettare commit, che non è un modo pulito di funzionare e può farti perdere le parti del nuovo codice che andava bene.
• Naturalmente, nelle primissime fasi di sviluppo, forse, puoi iniziare a lavorare direttamente sul master, ma dopo aver ottenuto qualcosa da consegnare, dovresti utilizzare i rami sviluppo, test o esperimento per non toccare la versione pubblicata, completa e funzionante.

In primo luogo, voglio sottolineare che in git, ogni pull è letteralmente un'operazione di ramificazione e ogni push è un'unione. Il master sul computer di uno sviluppatore è un ramo completamente separato da master su un repository centrale che condividi, con una posizione di parità dal punto di vista tecnico. Occasionalmente rinominerò la mia versione locale in upstream o qualcosa se si adatta meglio ai miei scopi.

Lo sottolineo perché molte organizzazioni pensano di utilizzare le filiali in modo più efficace del tuo collega, quando in realtà stanno facendo poco più che creare un nome aggiuntivo per un ramo lungo il percorso, che comunque non verrà salvato nella storia . Se il collega sta commettendo funzionalità in un commit atomico, è altrettanto facile eseguire il back-out come un commit di unione di un ramo di funzionalità. La stragrande maggioranza dei rami delle caratteristiche dovrebbe essere di breve durata e spesso unita in ogni caso.

Detto questo, i principali inconvenienti del suo modo di lavorare sono duplici. Innanzitutto, rende molto difficile collaborare a una funzionalità incompleta. Tuttavia, non sarebbe difficile creare un ramo solo in quei momenti in cui è necessaria la collaborazione.

In secondo luogo, rende molto difficile la revisione prima di unire. 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 test automatici passati per tutte le unioni. Se non stai facendo qualcosa di simile, francamente non stai usando git al 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 trasferibile sul master, ecc.) per lavorare direttamente sul master direttamente.

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

Hai branch di funzionalità, che sono unite in master o hai anche rami di release differenti o usi un processo completamente diverso?

"Non utilizzare il ramo principale" non è sufficiente.

One of our co-workers is quite happy making changes directly on the master branch, and despite several conversations, they seem not likely to change this.

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

Quindi, in tandem con un "non dovresti mai lavorare sul master", hai dei test delle funzionalità, testate ogni altro lavoro rivedete ogni altro 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 abitudini" nel lavorare direttamente sul ramo. Ma devi decidere cosa supporta meglio il tuo processo:

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

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

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