È un errore da principiante evitare la ramificazione? [duplicare]

La politica di rifiutare deliberatamente di ramificarsi è di solito un errore, ma non penso che la ramificazione sia fattibile nel tuo caso. Non perché stai usando SVN - che è la solita ragione per non usare i rami, dato che l'handle di SVN sui rami è particolarmente schifoso, anche se paragonato allo schifo generale di SVN - ma per questo:

our product can't be compiled and run locally, so our work is actually more like the whole team modifying a single test server.

Questo, IMO, è il tuo problema principale, e finché non lo aggiusterai, non penso che tu possa usare la ramificazione anche se lo volessi. Diversi sviluppatori non possono lavorare su rami separati poiché sono costretti a condividere una copia di lavoro. Se uno sviluppatore controlla un ramo, tale ramo verrà controllato dagli sviluppatori, il che significa che non si riesce a sfruttare il vantaggio principale della ramificazione, consentendo a più sviluppatori di lavorare su diverse funzionalità dello stesso progetto senza intralciarsi reciprocamente.

Quindi, non puoi usare le diramazioni per coordinare le collaborazioni, ma gli sviluppatori solitari (che usano SCM che non sono spazzatura totale - che non è il tuo caso qui, ma ignoriamolo per il punto del dibattito) usa anche la ramificazione - per esempio per testare nuove funzionalità che possono o non possono essere unite o per esplorare il sistema in un ramo raschiabile.

Può tu utilizzare i rami in questo modo? Bene, anche se stai bene con lo spostamento dell'intero team su un ramo di funzionalità o su un ramo raschiabile, come pensi di coordinarlo? Utilizzerai la posta elettronica o installerai un sistema PA in cui puoi annunciare CI STIAMO ORA TRASFERANDO PER CARATTERIZZARE LA FILIALE DI X ? E cosa farai quando qualche dev è nel mezzo di qualcosa nel ramo attuale? Li farai rotolare indietro o far sì che tutto il team aspetti che lo sviluppatore finisca?

Vuoi davvero quel mal di testa?

Un altro punto da considerare: la ramificazione di solito ha bisogno di un certo livello di pulizia nel processo di costruzione e nella struttura dell'albero del progetto, quindi gli artefatti di un ramo non perderanno su altri rami quando si cambia ramo. I progetti SCMed di solito hanno questo - altrimenti non sarebbero in grado di costruire su tutte le macchine di tutti gli sviluppatori - ma visto che il tuo progetto può solo costruire sul server di test dubito che tu abbia quel minimo livello di pulizia. Oh, probabilmente i tuoi rami funzioneranno, almeno all'inizio, finché un artefatto perdente ti sorprenderà con alcuni bug strani e difficili da rilevare.

È certamente un errore, ma non necessariamente solo un errore da principiante.

Nel mio ultimo lavoro (un lavoro di motorsports altamente competitivo) il mio capo era fermamente convinto di evitare la ramificazione. Aveva circa 20 anni di esperienza e pensava ancora che fosse una cattiva idea.

Sono completamente in disaccordo con lui e ho sfidato i suoi pregiudizi. Ci sono momenti in cui la ramificazione non vale la pena potenziale che porta. Tuttavia, ci sono altre volte in cui è chiaramente l'unica soluzione ragionevole (ad esempio, due team che fanno due iterazioni parallele ma separate di lavoro sullo stesso codice sorgente). Proprio come qualsiasi altra cosa nella vita, non dovresti avere una regola generale a riguardo.

Quindi sì, è un errore. No, non è solo un errore da principiante, anche se dovrebbe essere.

Tieni presente che l'unico scopo per la ramificazione è l'isolamento. Si dirama quando si desidera essere in grado di apportare modifiche nella posizione A senza incidere sulla posizione B. Avere un ramo aggiunge lavoro, quindi si desidera creare un ramo quando il vantaggio di avere il ramo supera il dolore dell'overhead coinvolto.

Ad esempio, la creazione di un ramo per correggere un piccolo bug è pazzesca: il lavoro necessario per creare un branch e unire è probabilmente molto più di quello che serve per correggere il bug. D'altra parte, vuoi assolutamente un ramo per una major release. Devi avere una base di codice stabile con correzioni controllate.

Qualunque cosa nel mezzo è un giudizio e dipende in realtà dalle dimensioni della squadra e da come funziona la squadra. Qui, lavoro su un team di 3 persone e abbiamo solo la linea principale e le filiali di rilascio. Se lavorassi in un gruppo di più di 10 persone, mi aspetterei che avremmo più filiali.

Ricorda inoltre che la profondità del ramo è importante perché determina quante fusioni devi fare. Una configurazione comune consiste nell'utilizzare i singoli rami di sviluppo che pendono da un ramo di integrazione, che quindi si blocca fuori dal main. In questo scenario, una correzione di bug da un ramo sviluppatore che va a un rilascio deve essere unita, costruita e testata 4 volte (dev- > integration- > main- > release). Si tratta di un sovraccarico, quindi è meglio avere vantaggi tangibili dall'avere quei rami.