tl; dr - Sembra che sia ora di fare un passo verso i campionati più importanti. Mettere il rossetto su un maiale non lo rende più carino, a meno che tu non sia interessato a quel genere di cose ...
Il problema delle persone
Il primo problema è la sincronizzazione del commit. Se hai più persone che lavorano sullo stesso codice allo stesso tempo, hai solo bisogno di una regola per evitare problemi:
Rule 1: Always pull before you merge/rebase
Quando si tratta di DVCS, è difficile apportare modifiche a un ramo remoto (ad esempio il repository principale) e molto semplice apportare modifiche al locale. Ogni persona è responsabile di inserire le proprie aggiunte di codice nell'insieme più grande senza problemi. A meno che 2 persone non si impegnino allo stesso tempo, non dovresti sperimentare. Impegnare l'accesso all'origine / master remoto dovrebbe essere limitato a pochi sviluppatori e dovrebbero estrarre le modifiche dagli altri sviluppatori tramite i rami di monitoraggio remoto.
Il problema del codice
Come fai a sapere che le modifiche apportate non interrompono il codice?
Risposta semplice ... Scrivi test per dimostrare che non lo fanno. Se ignori la scuola di pensiero TDD (Test Driven Design), l'intero punto di test è aggiungere un livello di verifica che ti permetta di cambiare codice senza romperlo.
Rule 2: Don't make assumptions, write proofs (ie tests).
Oltre a questo, è necessario eseguire l'intera gamma di test prima di passare al master di origine / remoto.
Tieni i tuoi impegni più piccoli e concisi possibili. In questo modo, se hai bisogno di eseguire il backup di una modifica che ha rotto qualcosa in seguito, risparmierai dal dover implementare nuovamente le parti che non hanno infranto il codice.
Potresti aver bisogno di alcune ristrutturazioni organizzative prima
Se le soluzioni di cui sopra non possono essere facilmente applicate, ci sono probabilmente alcuni problemi con la struttura di sviluppo che devono essere affrontati per primi.
Il proprietario del progetto dovrebbe essere il gatekeeper. Se ci sono problemi di sincronizzazione del commit, probabilmente ci sono troppe persone con accesso di commit. Anche su progetti di grandi dimensioni come il kernel di Linux, solo una manciata di sviluppatori ha effettuato l'accesso al repository master di origine / remoto. Esistono in realtà più livelli di repository per gestire i commit. Invece di un modello di commit a livello singolo in cui tutti stanno spingendo le loro modifiche all'origine, il modello gerarchico ha gatekeeper che estraggono le modifiche e ne verificano la qualità prima dell'inclusione nel progetto. Il modello di commit gerarchico può scalare molto più grande e più efficace del modello a singolo strato senza sacrificare la qualità.
Per gli sviluppatori che non ottengono l'accesso al commit, dovrebbero imparare a creare i propri rami di tracciamento remoto (git e gitorious vanno bene per questo) in modo che gli sviluppatori che fanno abbiano accesso di commit possono facilmente tirare / integrare rami nell'origine. Se le modifiche sono piccole, le patch funzioneranno altrettanto bene.
La possibilità di estrarre le modifiche prima di unire / rebase presuppone che non stai sviluppando sul tuo ramo principale locale. Il modo più semplice per gestirli è fare un pull iniziale prima di iniziare a programmare, quindi fare tutto il lavoro su quel ramo. Il modo più difficile è ramificarlo appena prima di unire e ripristinare il master.
Definisci lo stile di codifica per il progetto nel suo complesso e fai seguire gli sviluppatori. Gli sviluppatori contribuenti dovrebbero scrivere un codice conforme agli standard / norme del progetto per ridurre al minimo la pulizia. Lo stile di codifica può essere una grande barriera per l'ego in un progetto aperto. Se non è impostato uno standard, tutti codificheranno nel loro stile preferito e il codebase diventerà molto brutto molto velocemente.
Il mito di "The Mythical Man Month"
Che ci crediate o no, i progetti open source più grandi / di maggior successo non sono gestiti come una democrazia. Sono gestiti come una gerarchia. Dichiarare che un progetto non può crescere efficacemente oltre gli 8-10 sviluppatori è ingenuo. Se fosse vero allora i mega-progetti come il Kernel Linux non esisterebbero. Il problema più profondo è che dare accesso a tutti rende la comunicazione effetiva troppo difficile da gestire.
Il problema del mitico mese dell'uomo può essere superato. Hai solo bisogno di gestire il tuo progetto come l'esercito. Ci sono molti livelli all'interno della gerarchia perché è risaputo che le singole persone sono davvero efficaci solo nella gestione delle comunicazioni con una manciata di persone. Finché nessun singolo individuo è responsabile della gestione del lavoro di più di 5-7 persone, il sistema può scalare indefinitamente.
Potrebbe limitare gli sviluppatori migliori / esperti a fare più integrazione e progettazione / pianificazione di livello superiore, ma non è una cosa negativa. Parte del potenziamento sta facendo la mossa per decidere che il progetto ha bisogno di un piano a lungo termine. Le persone ai massimi livelli che hanno il maggiore investimento (il tempo è anche una risorsa) nei progetti futuri dovrebbero essere incaricati di prendere le decisioni più importanti.
È bello sapere di un progetto open source che sta attraversando dolori crescenti. Congratulazioni e buona fortuna.