Dev parallelo: gli sviluppatori dovrebbero lavorare all'interno dello stesso ramo?

Question

Se più sviluppatori lavorano all'interno dello stesso ramo e aggiornano - modifica - commit? O ogni sviluppatore dovrebbe avere il proprio/ogni proprio ramo in esclusiva? E in che modo i rami di condivisione potrebbero avere un impatto su un ambiente in cui si sta eseguendo una manutenzione ordinaria anziché flussi di codice non mantenuti? Inoltre, come funzionerebbe se distribuissi ciascun sviluppatore al lavoro appena eseguito e superasse i test (rapidamente, invece di mettere tutto il loro lavoro in una singola versione).

Answer 1

In generale, ho trovato che avere sviluppatori (che stanno lavorando sullo stesso progetto) utilizzano lo stesso ramo è meglio per trovare i problemi di integrazione prima. Se gli sviluppatori utilizzano ciascuno un singolo ramo, si stanno solo ritardando i possibili problemi di integrazione fino a più tardi, quando si uniscono i rami.

Ovviamente, avendo gli sviluppatori che lavorano sullo stesso ramo, è necessario avere una comunicazione effettiva tra questi sviluppatori, ma questo è un problema sociale e non tecnico.

Gli sviluppatori lavorerebbero su filiali separate quando esiste una buona ragione per la presenza di tale ramo in primo luogo (ad esempio una versione patch di una versione precedente del software o una build speciale per un cliente specifico).

Si noti che strumenti come Git e Mercurial consentono agli sviluppatori di creare facilmente le proprie filiali private per organizzare il proprio lavoro . Questa è una situazione diversa da parte di più di uno sviluppatore che condivide un ramo e dovrebbero essere incoraggiati i rami privati ​​(solitamente di breve durata).

Answer 2

I rami sono pensati come un modo per controllare la versione di qualsiasi funzione o codice sperimentale che potrebbe interrompere la linea principale/il trunk.

Mentre è comune per gli sviluppatori avere i propri rami personali per la sperimentazione profonda, spesso i rami si concentrano su una nuova funzione aggiunta. Queste nuove funzionalità spesso richiedono più di una persona da commettere.

Ad esempio, in un progetto Web, due sviluppatori e un progettista potrebbero eseguire un lifting sul proprio sito Web aziendale. Hanno ancora bisogno di mantenere pulito il loro codice di linea principale/codice di avviamento nel caso in cui debbano apportare una rapida modifica prima del completamento del lifting. Quindi creano un ramo "ringiovanimento del viso" e lavorano invece su quello. Mentre gli sviluppatori stanno commettendo javascript, il progettista può commettere CSS e immagini. Una volta completata la funzione di facelift, è possibile unirla alla linea principale e inviarla dal vivo.

L'unico motivo per cui uno di loro avrebbe bisogno di filiali personali sarebbe la sperimentazione. Forse il progettista sta cercando di implementare le schede "porta scorrevole" e, ad esempio, non è possibile ottenere il riempimento corretto in IE6. Se risolve il problema, può fonderlo nel ramo del lifting, se non può, semplicemente lo ignora e continua con il resto del disegno nel ramo del lifting.

Answer 3

In una certa misura, il software di controllo della versione in uso ti spingerà verso un particolare approccio. GIT è orientato verso i contributori open-source e assomiglia al modello "one developer" (la ramificazione non è nemmeno un concetto in GIT. GIT è più sulla gestione delle modifiche). Clearcase è più aziendale, quindi hai più sviluppatori su un ramo, ma ogni sviluppatore gioca a suo modo di vedere.

Sono d'accordo con la risposta di Greg, questo è più un problema di pianificazione sociale. Un sacco di sviluppatori su un ramo si calpesteranno l'un l'altro.Sono stato in un progetto in cui c'erano più sviluppatori rispetto ai singoli file sorgente :)

Answer 4

Penso che l'unione di filiali possa essere problematica (funzionalità disconnessa o incoerente), indipendentemente dalla qualità degli strumenti di controllo del codice sorgente. Preferisco di più optare per più sviluppatori che lavorano su un singolo ramo principale. Potrebbero esserci altri rami per cose come correzioni di bug di produzione o proof-of-concept (POC), dove la fusione potrebbe/dovrebbe avvenire molto presto dopo la modifica (correzioni di bachi) o buone probabilità che la fusione non debba necessariamente avvenire (POC).