Abbiamo bisogno di creare filiali locali per i miglioramenti su cui stiamo lavorando?

Il commit to master o trunk funziona fintanto che stai bene con come funziona.

Significa che se hai impegnato un po 'di codice da padroneggiare (e non lo hai spinto perché non è una cosa completa) e poi ti rendi conto che devi lavorare su qualcos'altro (lasciando questi commit in uno stato incompleto) - Diventa molto difficile farlo.

Esistono rami per separare gli sforzi di sviluppo e i ruoli che una determinata linea di codice può assumere.

Si consideri:

• Stai impacchettando una versione su master, e ora tutto ciò che non è il commit di questo è bloccato. Ciò interrompe un sacco di sviluppatori nelle loro tracce.
• Devi impegnare una correzione rapida in master e inviarla alla produzione.
• Devi lavorare su due attività separate contemporaneamente.
• Devi tenere a bada alcune funzionalità nel ramo master finché il marketing non dice "ok"
• Oops, quella caratteristica era un casino. Non impegnarlo a padroneggiare - oh aspetta, è già lì.

Questi sono solo alcuni dei problemi che si presentano a tutti coloro che si impegnano nel ramo principale. Se riesci a risolverli in altri modi, allora, non hai bisogno di rami. Tuttavia, i rami sono esattamente lo strumento utilizzato dalla maggior parte dei processi per risolvere questi problemi evitando blocchi di codice e inversioni improvvise di commit specifici.

Sottolineerò anche che niente di tutto questo ti impedisce di avere filiali locali. Si potrebbe facilmente estrarre il master, il branch locale, il rebase in cima al master, eliminare il ramo locale e quindi inviarlo nuovamente al master remoto e nessuno sarebbe più saggio. Personalmente Sento che avere filiali e fusioni che mostrano più informazioni sulla storia del codice è utile, ma questo è personalmente. Forse al tuo amministratore non piace vedere tutti quei rami e vuole solo vedere il ramo principale - ci sono persone così. Ma ciò non significa non diramazione locale: significa semplicemente non spingere i rami indietro verso il telecomando e ripulire tutto prima di fare quella spinta.

Vedi la domanda sopra collegata per, penso, un Q & A completo sul ruolo del ramo principale.

Tuttavia, per rispondere ulteriormente alla tua domanda, è importante capire perché i rami funzione sono importanti. Se tutti si stanno sviluppando e spingono verso lo stesso ramo, allora cosa succede quando qualcuno dimentica di archiviare un file, o controlla le cose sbagliate, o rovina tutto in un rebase?

Nella nostra organizzazione utilizziamo GitFlow , con il ramo principale rimasto inutilizzato. Sviluppare è la punta di lavoro degli sforzi della versione corrente, i rilasci sono nelle filiali nominate e le caratteristiche sono tutte sviluppate su rami (si spera siano di breve durata).

Con i rami funzione, siamo in grado di eseguire una configurazione CI completa su ogni ramo prima che viene unito per lo sviluppo. Insieme a una richiesta di pull approvata, la build del ramo deve essere verde prima che si verifichi l'unione. Ciò garantisce che il codice da unire compili e superi tutti i test automatici. Questo processo ci ha consentito di cogliere il più semplice dei problemi il prima possibile nel ciclo di sviluppo.