tl; dr - Parece que es hora de pasar a las grandes ligas. Poner lápiz labial en un cerdo no lo hace más bonito, a menos que te guste ese tipo de cosas ...
El problema de las personas
El primer problema es la sincronización de confirmación. SI tiene varias personas trabajando en el mismo código al mismo tiempo, solo necesita una regla para evitar problemas:
Rule 1: Always pull before you merge/rebase
Cuando se trata de DVCS, es difícil hacer cambios en una rama remota (es decir, el repositorio principal) y es muy fácil hacer cambios en el local. Cada persona es responsable de hacer que sus propias adiciones de código encajen en el todo sin problemas. A menos que 2 personas se comprometan al mismo tiempo, no deberías experimentar. El acceso de compromiso al origen / maestro remoto debe limitarse a solo unos pocos desarrolladores y deben extraer los cambios de los otros desarrolladores a través de ramas de seguimiento remoto.
El problema del código
¿Cómo sabes que los cambios que haces no rompen el código?
Respuesta simple ... Escribe pruebas para demostrar que no. Si ignora la escuela de pensamiento TDD (Test Driven Design), el objetivo de las pruebas es agregar un nivel de verificación que le permita cambiar el código sin romperlo.
Rule 2: Don't make assumptions, write proofs (ie tests).
Además de esto, se debe ejecutar toda la gama de pruebas antes de pasar al origen / maestro remoto.
Mantenga sus compromisos tan pequeños y concisos como sea posible. De esa manera, si necesita retroceder un cambio que rompió algo más adelante, evitará tener que volver a implementar las partes que no rompieron el código.
Es posible que primero necesite una reestructuración organizacional
Si las soluciones anteriores no se pueden aplicar fácilmente, probablemente haya algunos problemas con la estructura de desarrollo que deben abordarse primero.
El propietario del proyecto debe ser el guardián. Si hay problemas de sincronización de confirmación, probablemente haya demasiadas personas con acceso de confirmación. Incluso en proyectos masivos como el kernel de Linux, solo un puñado de desarrolladores tiene acceso de acceso al repositorio maestro de origen / remoto. En realidad, existen múltiples niveles de repositorios para administrar las confirmaciones. En lugar de un modelo de confirmación de una sola capa donde todos están empujando sus cambios al origen, el modelo jerárquico tiene guardianes que realizan cambios y verifican su calidad antes de incluirlos en el proyecto. El modelo de confirmación jerárquica puede escalar mucho más grande y más eficaz que el modelo de una sola capa sin sacrificar la calidad.
Para los desarrolladores que no consiga acceso de envío, deben aprender a crear su propia ramas de seguimiento remoto (GIT y gitorious son buenos para esto) para que los desarrolladores que hacen hayan acceso de confirmación puede tirar fácilmente / integrar ramas en el origen. Si los cambios son pequeños, los parches funcionarán igual de bien.
La capacidad de realizar cambios antes de hacer una fusión / rebase supone que no está desarrollando en su rama maestra local. La forma más fácil de manejar esto es hacer una extracción inicial antes de comenzar a codificar, luego hacer todo su trabajo en esa rama. La forma difícil es bifurcarlo justo antes de fusionarlo y deshacer el master.
Defina el estilo de codificación para el proyecto en general y haga que los desarrolladores lo sigan. Los desarrolladores contribuyentes deben escribir código que se ajuste a los estándares / normas del proyecto para minimizar la limpieza. El estilo de codificación puede ser una gran barrera para el ego en un proyecto abierto. Si no se establece un estándar, todos codificarán en su propio estilo preferido y la base de código se volverá muy fea muy rápido.
El mito del "Mes del hombre mítico"
Lo creas o no, los proyectos de código abierto más grandes / más exitosos no se ejecutan como una democracia. Se ejecutan como una jerarquía. Afirmar que un proyecto no puede crecer efectivamente más allá de 8-10 desarrolladores es ingenuo. Si eso fuera cierto, entonces no existirían megaproyectos como el Kernel de Linux. El problema más profundo es que otorgar acceso de compromiso a todos simplemente hace que la comunicación efectiva sea demasiado difícil de manejar.
El problema del mes mítico del hombre puede ser superado. Solo necesita ejecutar su proyecto como los militares. Hay muchos niveles dentro de la jerarquía porque es de conocimiento común que las personas individuales solo son realmente efectivas en la gestión de las comunicaciones con un puñado de personas. Mientras ningún individuo sea responsable de administrar el trabajo de más de 5-7 personas, el sistema puede escalar indefinidamente.
Puede limitar a los desarrolladores mejor / experimentados a hacer más integración y diseño / planificación de alto nivel, pero eso no es algo malo. Parte de la ampliación es hacer el movimiento para decidir que el proyecto necesita un plan a largo plazo. Las personas en los niveles más altos que tienen la mayor inversión (el tiempo también es un recurso) en el futuro del proyecto deben ser las encargadas de tomar las grandes decisiones.
Es bueno escuchar sobre un proyecto de código abierto que atraviesa dificultades de crecimiento. Felicidades y buena suerte.
