È buona norma avere un ramo remoto per ogni sviluppatore?

Probabilmente non darei ad ogni sviluppatore un ramo sul server centrale a meno che tu non abbia una sorta di infrastruttura in stile github che permetta loro di creare e distruggere i rami stessi e documentare chiaramente a cosa servono. Alcuni sviluppatori avranno bisogno di più di un ramo e alcuni non ne avranno affatto bisogno, ma tu stai creando confusione per tutti da ordinare e spese generali amministrative per te stesso.

Vorrei incoraggiare invece il tipo di git di condivisione organico eccelle in. È molto facile creare un clone sul proprio computer e trasformarlo in una condivisione SMB di sola lettura da cui gli altri possono effettuare il pull. In effetti, mi sorprenderebbe molto se molti dei tuoi sviluppatori non lo stessero già facendo.

Dipende da come sono organizzati il team di sviluppo e le attività. A mio parere, il modello che hai specificato funzionerebbe meglio se:

1. Ogni sviluppatore lavora autonomamente su attività indipendenti.
2. Tutti gli sviluppatori contribuiscono allo stesso compito.

Dove questo potrebbe non funzionare bene è se in sviluppo ci sono progetti di feature concorrenti e ognuno di essi ha più sviluppatori che lavorano su di essi.

Dare a ciascuno sviluppatore la propria filiale può essere utile se tutti lavorano su cose diverse che potrebbero toccare gli stessi file. Può aiutare a evitare di calpestare le dita degli altri, ma è necessario che ognuno si unisca spesso e sia responsabile nella gestione dei conflitti. Questo è ciò che viene fatto nel mio ufficio e funziona piuttosto bene a parte il raro giorno in cui devi unire manualmente metà dei file che hai modificato.

Se più sviluppatori lavorano sulla stessa funzione, probabilmente è meglio creare filiali basate sulla funzione in sviluppo piuttosto che sullo sviluppatore.

Se collabori con Git, dovresti provare Pull Requests.

In breve, per prima cosa unisci il ramo master al tuo attuale ramo di lavoro. Eventuali conflitti di unione si verificheranno nella filiale locale. Questo è bello perché il tuo ramo principale non è mai rotto. Se ti fotti davvero, hai il commit locale che puoi ripristinare.

Una volta completata l'unione, chiedi a qualcun altro del team di rivedere e unire il tuo ramo nel ramo principale. Mai unire il tuo! Fintanto che nessuno è entrato di nascosto e ha fatto un'altra richiesta di pull, è garantito che si unisca correttamente. Dato che tutti sono a conoscenza della richiesta di pull, non dovresti avere più persone che si uniscono in master contemporaneamente allo stesso tempo.

Una volta che ti sei abituato a questo processo, dovresti cercare di unire il più spesso possibile - una sorta di integrazione continua di un povero. Meno tempo trascorre tra i conflitti, meglio è. Identificherete quando due persone duplicano gli sforzi e possono collaborare. Alcuni posti si uniranno ogni volta che completano un requisito, che potrebbe essere ogni due ore. Raccomando di fondere almeno una volta alla settimana; altrimenti devi interrompere le tue attività in modo migliore.

Generalmente creo un ramo per attività. Git è bello perché distingue tra commit locali e spinte. Ciò fornisce alcuni dei vantaggi di ogni persona che ha il proprio ramo senza tutta la complessità.