tl; dr - Hört sich an, als wäre es an der Zeit, zu den großen Ligen aufzusteigen. Wenn Sie einem Schwein Lippenstift geben, wird es nicht schöner, es sei denn, Sie mögen so etwas ...
Das Menschenproblem
Das erste Problem ist die Festschreibungssynchronisierung. WENN mehrere Personen gleichzeitig an demselben Code arbeiten, benötigen Sie nur eine Regel, um Probleme zu vermeiden:
Rule 1: Always pull before you merge/rebase
Wenn es um DVCS geht, ist es schwierig, Änderungen an einem entfernten Zweig (dh dem Haupt-Repository) vorzunehmen, und es ist sehr einfach, Änderungen am lokalen Zweig vorzunehmen. Jede Person ist dafür verantwortlich, dass ihre eigenen Code-Ergänzungen problemlos in das Gesamtbild passen. Es sei denn, 2 Personen verpflichten sich genau zur gleichen Zeit, sollten Sie nicht erfahren. Der Commit-Zugriff auf den Ursprungs- / Remote-Master sollte auf wenige Entwickler beschränkt sein, und sie sollten Änderungen von den anderen Entwicklern über Remote-Tracking-Zweige abrufen.
Das Code-Problem
Woher wissen Sie, dass die vorgenommenen Änderungen den Code nicht beschädigen?
Einfache Antwort ... Schreiben Sie Tests, um zu beweisen, dass dies nicht der Fall ist. Wenn Sie die TDD (Test Driven Design) -Schule ignorieren, besteht der springende Punkt der Tests darin, eine Überprüfungsebene hinzuzufügen, mit der Sie Code ändern können, ohne ihn zu beschädigen.
Rule 2: Don't make assumptions, write proofs (ie tests).
Darüber hinaus sollte die gesamte Bandbreite der Tests ausgeführt werden, bevor Sie einen Push an den Origin / Remote-Master senden.
Halten Sie Ihre Commits so klein und prägnant wie möglich. Auf diese Weise ersparen Sie sich die Neuimplementierung der Teile, die den Code nicht beschädigt haben, wenn Sie eine Änderung rückgängig machen müssen, die später zu Problemen geführt hat.
Möglicherweise müssen Sie zuerst die Organisation neu strukturieren
Wenn die obigen Lösungen nicht einfach angewendet werden können, gibt es wahrscheinlich einige Probleme mit der Entwicklungsstruktur, die zuerst behoben werden müssen.
Der Eigentümer des Projekts sollte der Gatekeeper sein. Bei Problemen mit der Commit-Synchronisierung sind wahrscheinlich zu viele Personen mit Commit-Zugriff beschäftigt. Selbst bei umfangreichen Projekten wie dem Linux-Kernel haben nur eine Handvoll Entwickler Zugriff auf das Origin / Remote-Master-Repository. Es gibt tatsächlich mehrere Ebenen von Repositorys, um Commits zu verwalten. Anstelle eines einschichtigen Festschreibungsmodells, bei dem alle ihre Änderungen an den Ursprung verschieben, verfügt das hierarchische Modell über Gatekeeper, die Änderungen abrufen und deren Qualität überprüfen, bevor sie in das Projekt aufgenommen werden. Das hierarchische Festschreibungsmodell kann wesentlich größer und effektiver skaliert werden als das Einzelschichtmodell, ohne dass die Qualität beeinträchtigt wird.
Entwickler, die keinen Commit-Zugriff erhalten, sollten lernen, ihre eigenen Remote-Tracking-Zweige zu erstellen (Git und Gitorious sind dafür gut), damit Entwickler, die über Commit-Zugriff verfügen, problemlos Zweige in den Ursprung ziehen / integrieren können. Wenn die Änderungen gering sind, funktionieren Patches genauso gut.
Die Möglichkeit, Änderungen vor dem Zusammenführen / Wiederherstellen abzurufen, setzt voraus, dass Sie nicht in Ihrer lokalen Hauptniederlassung entwickeln. Die einfache Möglichkeit, dies zu handhaben, besteht darin, einen ersten Pull durchzuführen, bevor Sie mit dem Code beginnen, und dann Ihre gesamte Arbeit an diesem Zweig auszuführen. Der schwierige Weg ist, es kurz vor dem Zusammenführen zu verzweigen und den Master zurückzusetzen.
Definieren Sie den Codierungsstil für das Projekt insgesamt und lassen Sie die Entwickler ihm folgen. Mitwirkende Entwickler sollten Code schreiben, der den Standards / Normen des Projekts entspricht, um die Bereinigung zu minimieren. Coding-Stil kann eine große Ego-Barriere in einem offenen Projekt sein. Wenn kein Standard festgelegt ist, wird jeder in seinem bevorzugten Stil codieren und die Codebasis wird sehr schnell sehr hässlich.
Der Mythos von "The Mythical Man Month"
Ob Sie es glauben oder nicht, die größeren / erfolgreicheren Open Source-Projekte laufen nicht wie eine Demokratie. Sie werden als Hierarchie geführt. Es ist naiv zu behaupten, dass ein Projekt nicht effektiv über 8-10 Entwickler hinauswachsen kann. Wenn das wahr wäre, gäbe es keine Megaprojekte wie den Linux-Kernel. Das tiefere Problem ist, dass es zu schwierig ist, eine effektive Kommunikation zu handhaben, wenn jedem ein Commit-Zugriff gewährt wird.
Das Problem des mythischen Mannmonats kann tatsächlich überwunden werden. Sie müssen Ihr Projekt nur wie das Militär betreiben. Es gibt viele Ebenen innerhalb der Hierarchie, da es allgemein bekannt ist, dass einzelne Personen nur mit einer Handvoll von Personen effektiv kommunizieren können. Solange keine einzelne Person für die Verwaltung der Arbeit von mehr als 5-7 Personen verantwortlich ist, kann das System unbegrenzt skaliert werden.
Möglicherweise beschränken sich die besten / erfahrenen Entwickler darauf, mehr Integration und übergeordnetes Design / Planung durchzuführen, aber das ist keine schlechte Sache. Ein Teil der Skalierung besteht darin, zu entscheiden, dass das Projekt einen langfristigen Plan benötigt. Die Menschen auf höchster Ebene, die die größte Investition (Zeit ist auch eine Ressource) in die Zukunft des Projekts haben, sollten mit den großen Entscheidungen beauftragt werden.
Es ist schön zu hören, dass ein Open-Source-Projekt immer mehr Probleme hat. Herzlichen Glückwunsch und viel Glück.