He leído sobre Integration Manager Workflow, y parece muy adecuado para nuestro proceso de desarrollo (un desarrollador principal para el proyecto, que revisa el trabajo de otros desarrolladores antes de comprometerse con el repositorio del proyecto).Git Integration Manager Workflow: uno o varios repositorios?
Sin embargo, una cosa no está clara para mí. En esta visualización del libro Git Pro parece como si cada desarrollador tiene su propio repositorio (a distancia) para empujar a:
en this chapter (sección "Personas de la pequeña privada"), sin embargo, parecen usar ramas para lograr el mismo tipo de flujo de trabajo.
¿Es esto correcto? ¿Qué táctica deberíamos usar? sucursales o repositorios múltiples? Supongo que es más difícil mantener un cronograma de compromisos si extraes el trabajo de un repositorio diferente.
Pero, ¿también es posible tener un repositorio central, con los desarrolladores que no son mantenedores solo presionando ramas adicionales, que el mantenedor luego se fusiona en el maestro? – Rijk
Ah, su ejemplo es muy claro, gracias. ¿Este flujo de trabajo tiene alguna desventaja en comparación con hacer todo esto en un repositorio (por ejemplo, historial de commit perdidos, etc.)? – Rijk
El problema es con git, nunca tienes un solo repositorio :) Los desarrolladores siempre tendrán un repositorio propio. Es solo cuestión de cómo quieres que parezca el repositorio DAG, es decir, quién empuja qué a qué repos, o quién saca qué, etc. ¿Tiene algún sentido? – ralphtheninja