Quali sono i vantaggi dell'uso della ramificazione come sviluppatore singolo?

I vantaggi sono per lo più gli stessi dei gruppi di sviluppatori. Utilizzando un ramo master sempre pronto per la release e i rami delle funzionalità per lo sviluppo di nuove funzionalità, è sempre possibile rilasciare il master. Trova un bug importante mentre lavori su una funzione? Cambia succursale, correggi, rilascia, torna indietro e continua a sviluppare.

O forse questo è un progetto per hobby e ti piace solo essere in grado di lavorare un po 'su questa funzione e un po' di quello, dato che l'atmosfera ti colpisce. In pratica stai emulando un team composto da più persone tagliando il tempo.

La ramificazione implicita che i DVCS fanno sui cloni significa che i rami formali sul repository autorevole sono meno relativi al coordinamento delle persone e più al coordinamento delle direzioni di sviluppo, e persino una singola persona può fare più di quelle.

Sviluppo a lungo termine

La ramificazione per un team di una sola persona sarebbe utile per una funzione di sviluppo di lunga durata che altrimenti non si adatta al ciclo di rilascio.

Puoi prendere una filiale per il tuo cambiamento di spanning di più mesi ed essere ancora in grado di inviare le correzioni di bug giornaliere o le modifiche dal tuo ramo principale ad intervalli regolari.

Questo ha il vantaggio rispetto agli 'switch' in un singolo ramo in quanto il tuo ramo principale è sempre in uno stato distribuibile e ti è garantito che nulla nella funzione long running ha avuto un impatto su altro codice precedentemente testato.

Funzioni sperimentali

Un ramo può anche essere utile per le funzionalità che potresti desiderare di prototipare, ma che potrebbero non essere mai inserite nel tuo codice distribuito. Il completamento di questi su un ramo che alla fine viene buttato via significa che non si inquina mai inutilmente il codice base principale.

Lo uso per la manutenzione critica del sito web. Sono l'unico sviluppatore, ma ho un master, sviluppo ed emissione di rami.

Il mio processo di lavoro per l'impostazione del sito è simile a questo:

1. Rendi il ramo principale utilizzabile. Effettua il commit iniziale.

2. Acquista il ramo. Non fare nulla, sviluppare funzioni come buffer di test per l'unione in master.

3. Estratto problema ramo. Codifica il problema, quando è terminato, esegui lo sviluppo, verifica eventuali problemi, unisci conflitti, ecc .. risolvili.

Quando un numero sufficiente di problemi viene unito per lo sviluppo di una release e lo sviluppo è stato testato per la stabilità, pull diventa master.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

In questo modo puoi sviluppare una raccolta completa di test, dove puoi testare stabilità, problemi, ecc ... senza dover rischiare di danneggiare il Master e dover eseguire il rollback dei commit se fossero dannosi.

Inoltre, utilizzando i singoli rami per il commit, puoi "lasciare" il lavoro che hai già fatto, ricominciare da capo con qualcos'altro per risolvere un problema più urgente e farlo uscire prima.

Nella vita reale di solito ho un ramo di un problema, e lo tiro in sviluppo e poi in master. A volte è noioso, ma almeno una volta ogni due mesi devo lasciare il lavoro alla goccia di un cappello perché qualcuno ha avuto l'idea che devo fare RightNow ™ e in questo modo posso tornare rapidamente a uno stato base, creare la cosa e poi dopo continua dove ero. Soprattutto con progetti di grandi dimensioni che richiedono più settimane, è una divinità che posso cambiare rapidamente rami.

Considera questo scenario: lavori sempre su un ramo principale e hai AwesomeCodeThing ™ nelle opere che lasciano il tuo ramo Master in chirurgia a cuore aperto e compare un YugeBug ™ che ha bisogno di un aggiustamento urgente altrimenti migliaia di utenti si lamenteranno di te BigProblems ™
L'unico modo per risolvere rapidamente il problema in uno scenario del genere,

1. controlla i tuoi precedenti commit,
2. controlla quando è stato eseguito l'ultimo commit stabile (cursing è facoltativo)
3. torna a quel commit
4. crea correzione, applica la correzione alla produzione
5. risolvi tutti i conflitti e i problemi che ora cerchi di tornare allo stato di AwesomeCodeThing ™
6. mollare, piangere e iniziare a lavorare. (opzionale)

Se utilizzi i rami:

1. Checkout master
2. crea una diramazione UrgentFix ™ e aggiusta le cose
3. estrai UrgentFix ™ nel master
4. invia alla produzione
5. Unisci master in sviluppo
6. Unisci sviluppo in AwesomeCodeThing ™
7. prendi una birra e continua a lavorare.

Le filiali facilitano il lavoro su più funzioni contemporaneamente, il che può essere molto utile quando le priorità cambiano durante il corso di un progetto.

Supponiamo che tu decida che una funzionalità è più importante ora. Forse hai urgentemente bisogno di correggere un bug critico in un sistema live. Potresti lavorare con un cliente su più funzioni per un lungo periodo di tempo e potresti voler dimostrare separatamente i progressi di ciascuna funzione. Forse hai appena letto su un brutto exploit zero day e vuoi andare su di esso prima che il cliente lo legga.

Se utilizzi i rami per ogni funzione / hotfix, in genere sarà più semplice, più pulito e più rapido isolare e distribuire queste modifiche anziché utilizzare un singolo ramo per tutto. Questo è vero se sei un unico sviluppatore o parte di un team.

Per quanto riguarda un processo reale, trovo che il flusso git funzioni bene. Il di Git flow cheat di Daniel Kummer è una grande risorsa, vale la pena guardare anche se non stai usando git .

Come menzionato da altri utenti, i vantaggi sono sostanzialmente simili al lavoro in team: la capacità di sviluppare e testare le funzionalità in modo indipendente, mantenere un ramo master separato per hotfix / deployment di produzione, esperimento.

Per quanto mi riguarda, generalmente tendo a lavorare in master se conosco molto bene l'area su cui sto lavorando, ma aggiungo solo un overhead al branch perché li unirò comunque.

Tuttavia, se ho nessuna esitazione riguardo alle modifiche che sto facendo, sostituirò solo PR / unire una volta che il ramo si comporta come previsto e generalmente è completamente testato. In questo modo, se scopro un problema per cui il rollback è il miglior modo di agire, è un singolo commit al posto di un'intera serie (non ricordo mai la sintassi per il rollback di una serie di commit ma uno solo è facile).