Ho visto i rami degli sviluppatori utilizzati in due scenari principali:
La comunità open source, in cui questi rami sono in realtà fork di repository, in modo che i manutentori del progetto possano bloccare l'accesso al repository principale e richiedere l'integrazione tramite richieste pull. Questo rende la vita più difficile per i collaboratori, ma molto più facile per i manutentori, che ovviamente è esattamente il punto, e questo è un modello di grande successo su GitHub.
Team e organizzazioni che non dispongono di una continua integrazione e di precedenti di instabilità nelle loro distribuzioni, o peggio, di instabilità nelle loro build. Questi team generalmente cercano di utilizzare i rami degli sviluppatori come modo per proteggere la stabilità della linea principale e il risultato è - in genere - un periodo di fusione lungo e molto doloroso prima del rilascio, seguito da un periodo di stabilizzazione ancora più lungo e più doloroso, che a volte non succede fino a dopo il rilascio.
Non voglio che questo sia un vaneggiamento sul perché hai bisogno di CI, ma dalla tua domanda è chiaro che sai che non stai integrando le tue modifiche abbastanza spesso, quindi IMO non ha senso ballare attorno al problema.
A meno che tu non stia effettivamente lavorando in un team distribuito geograficamente con la necessità di "bloccare" le modifiche da sviluppatori esterni, il modello di filiale per sviluppatore non ha molto senso. In particolare non ha senso con Git, perché ogni sviluppatore ha già tecnicamente il proprio repository. La maggior parte delle organizzazioni dovrebbe integrarsi molto frequentemente - come in, più volte al giorno.
Attualmente faccio parte di un gruppo di circa 35 collaboratori suddivisi in 4 squadre separate, la maggior parte delle persone effettua il check-in almeno 2-3 volte al giorno, alcune persone 10-15 volte; è insolito vedere le build rotte ed estremamente rare per loro rimanere rotti per più di qualche minuto. Git gestisce le fusioni così facilmente per la maggior parte del tempo che i rami degli sviluppatori remoti sono semplicemente inutili. Basta tirare, unire localmente ed eseguire i test di commit prima di spingere, è semplice.
Se è assolutamente necessario rinviare l'integrazione al fine di proteggere la stabilità del ramo principale, il tipico, collaudato modello è quello di utilizzare un ramo unstable - a volte chiamato un ramo di sviluppo , come descritto in un modello di ramificazione Git successo . Se gli sviluppatori non riescono a fondersi con successo in questo ramo (che deve solo essere costruito , non eseguito in modo impeccabile) almeno una volta al giorno, allora hai un problema di qualità / disciplina e non un problema di controllo della revisione; coprirlo usando filiali di sviluppatori non integrate non fa altro che difendere il problema e, in tal modo, rende effettivamente le eventuali fusioni molto più dolorose e instabili di quanto debbano realmente essere.
I rami delle caratteristiche non sono i peggiori, ma pochi progetti dell'IMO sono in realtà abbastanza grandi da giustificarli; se il tuo progetto è molto grande (cioè tonnellate di funzionalità su cui si sta lavorando contemporaneamente), vedrai risultati migliori dalla suddivisione in componenti autonomi separati rispetto a quelli che coprono il problema con il controllo del codice sorgente.
Puoi ignorare questo consiglio se vuoi, e molti team lo fanno, ma uno dei motivi per cui il modello di diramazione collegato sopra è così popolare e di successo è che è progettato per funzionare con un'integrazione continua, non contro di esso.