Quali sono i vantaggi dell'utilizzo delle diramazioni come sviluppatore solista?

Prima di tutto, sono consapevole che sono state poste molte domande su VCS come sviluppatore solista, ma spesso sono troppo ampie. Ciò riguarda solo la ramificazione, ed è ancora stato contrassegnato come duplicato ... il presunto duplicato è, ancora una volta, contrassegnato come un altro duplicato di un'altra domanda che è troppo ampia e non riguarda la ramificazione in modo specifico. Ecco come la mia domanda è unica.

Quali sono i vantaggi dell'utilizzo della ramificazione come sviluppatore solista? L'ho visto spesso raccomandato anche in un contesto solo-dev, ma per quanto posso vedere, oltre a usare un trunk "master" per lo sviluppo e diramare per lavorare, codice pronto per il rilascio, non vedo come Potrei sfruttare il potere della ramificazione (ad esempio, per compartimentare nuove funzionalità) senza complicare eccessivamente l'intero processo di sviluppo.

I vantaggi sono principalmente gli stessi dei gruppi di sviluppatori. Utilizzando un ramo master sempre pronto per il rilascio e rami di funzioni per lo sviluppo di nuove funzionalità, è sempre possibile rilasciare il master. Trova un bug importante mentre lavori su una funzione? Cambia ramo, correggi, rilascia, torna indietro e continua lo sviluppo.

O forse questo è un progetto per hobby e ti piace essere in grado di lavorare un po 'su questa funzione e un po' di quello, quando l'umore ti colpisce. Fondamentalmente stai emulando un team di più persone tagliando il tempo.

La ramificazione implicita che i DVCS fanno sui cloni significa che le ramificazioni formali nel repository autorevole riguardano meno il coordinamento delle persone e più il coordinamento delle direzioni di sviluppo, e anche una sola persona può fare più di queste.

Sviluppo a lungo termine

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

Puoi prendere una succursale per il tuo cambiamento di spanning di più mesi ed essere ancora in grado di inviare a intervalli regolari qualsiasi correzione di bug o modifica quotidiana dal tuo ramo principale.

Questo ha il vantaggio rispetto agli "switch" in un singolo ramo in quanto il tuo ramo principale è sempre in uno stato distribuibile e hai la garanzia che nulla nella funzionalità di lunga durata ha avuto un impatto su altro codice precedentemente testato.

Caratteristiche sperimentali

Un ramo può anche essere utile per le funzionalità che potresti voler prototipare, ma che potrebbero non trasformarlo mai nel tuo codice distribuito. Completare questi su un ramo che alla fine verrà buttato via significa che non inquinerai mai inutilmente la tua base di codice principale.

Lo uso per la manutenzione di siti Web critici. Sono l'unico sviluppatore eppure ho un master, sviluppo e rilascio di filiali.

Il mio processo di lavoro per l'installazione del sito è simile al seguente:

1. Rendi il ramo master praticabile. Effettua il commit iniziale.

2. Acquista sviluppo ramo. Non fare nulla, sviluppa funzioni come buffer di test da unire al master.

3. Filiale di emissione del checkout. Codifica il tuo problema, una volta terminato, spingilo nello sviluppo, vedi se sorgono problemi, unisci conflitti ecc ... risolvili.

Quando un numero sufficiente di problemi viene unito allo sviluppo per una versione e lo sviluppo è stato testato per la stabilità, tirare lo sviluppo in master.

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

In questo modo ottieni una raccolta completa di test in fase di sviluppo, in cui puoi testare stabilità, problemi, ecc ... senza dover rischiare di ferire il Maestro e dover annullare i commit se fossero dannosi.

Inoltre, usando le singole filiali per impegnarsi, puoi "lasciare" il lavoro che hai già fatto, ricominciare da capo per qualcos'altro per risolvere un problema più urgente e distribuirlo prima.

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

Consideriamo questo scenario: sempre lavora su un ramo principale e si dispone AwesomeCodeThing ™ nelle opere che lascia la filiale Master in chirurgia a cuore aperto e un YugeBug ™ apre che ha bisogno di fissaggio urgente altrimenti migliaia di utenti si lamentano con te di BigProblems ™
The l'unico modo per risolvere rapidamente il problema in tale scenario,

1. controlla i tuoi precedenti impegni,
2. vedere quando è stato eseguito l'ultimo commit stabile (la maledizione è facoltativa)
3. tornare a quel commit
4. fare la correzione, spingere la correzione fuori alla produzione
5. risolvi tutti i conflitti e i problemi che ora stai provando a tornare allo stato di AwesomeCodeThing ™
6. rinunciare, piangere e ricominciare da capo (opzionale)

Se usi i rami:

1. Checkout master
2. creare un ramo UrgentFix ™ e sistemare le cose
3. tira UrgentFix ™ nel master
4. spingere alla produzione
5. Unisci master in sviluppo
6. Unisci lo sviluppo in AwesomeCodeThing ™
7. prendi una birra e continua a lavorare.

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

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

Se si utilizzano i rami per ogni funzionalità / hotfix, in genere sarà più facile, più pulito e rapido isolare e distribuire queste modifiche anziché utilizzare un singolo ramo per tutto. Questo vale sia che tu sia un unico sviluppatore o parte di una squadra.

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

Come menzionato da altri poster, i vantaggi sono sostanzialmente simili al lavoro in team: capacità di sviluppare e testare autonomamente funzionalità, mantenere un ramo master separato per hotfix / distribuzioni di produzione, esperimento.

Per quanto mi riguarda, in genere tendo a lavorare come maestro se conosco molto bene l'area su cui sto lavorando, aggiunge solo un sovraccarico al ramo perché li unirò comunque.

Tuttavia, se ho qualche esitazione sulle modifiche che sto apportando, diramerò e unirò PR / unirò una volta che il ramo si comporterà come previsto ed è generalmente completamente testato. In questo modo, se scopro un problema per il quale il rollback è la migliore linea d'azione, è un singolo commit anziché un'intera serie (non ricordo mai la sintassi per il rollback di una serie di commit, ma una sola è facile).