Ho visto che i team di sviluppo solitamente usano il controllo del codice sorgente in uno dei due schemi:
O "Feature Branch", in cui ogni funzione è sviluppata in un nuovo ramo, o "Developer Branch", dove ogni sviluppatore del team ha un ramo dedicato per il suo lavoro.
Capisco le differenze tecniche, ma non capisco davvero quando è meglio usare ogni schema.
Uso principalmente HG, ma non credo che importi
Dalla mia esperienza, i rami di funzionalità sono strettamente più generici e flessibili. Il vantaggio è che i rami di funzionalità consentono a uno sviluppatore di lavorare su più rami contemporaneamente - e anche a più sviluppatori di lavorare sullo stesso ramo, se necessario, senza confusione ("Perché Joe scrittura si impegna sul ramo Bob ...? ").
L'uso di rami specifici dello sviluppatore, anche se inizialmente è più semplice, può causare frizione quando si lavora su più funzioni contemporaneamente (cose come git stash possono essere usate per evitare questo, ma a costo di una trasparenza ridotta).
E forse uno dei problemi più importanti è che perdi un po 'di informazioni semantiche quando usi rami specifici dello sviluppatore. La linea:
git merge topnav-style-change
è semplice e può aiutare a evitare errori (non potrebbe, per esempio, essere facilmente confuso con il ramo massive-refactoring ). D'altra parte,
git merge joe
non trasmette molto da solo ("Era Joe o Bob che stava lavorando sui cambiamenti di stile ...?").
Per questi motivi, in generale, vedo più progetti al giorno d'oggi usando i rami delle caratteristiche. Tuttavia, le due scelte non sono necessariamente esclusive: potrebbero essere utilizzate insieme così come sono, o anche in una sorta di mix ibrido. Dipende davvero dalla complessità e dalle esigenze del tuo progetto.
Leggi altre domande sui tag git version-control branching mercurial