Estructuración de componentes relacionados en git

Question

Mi equipo está considerando pasar de aproximadamente 2 docenas de repositorios de subversión a repositorios git. Lo que estamos tratando de remediar es que actualmente, cada uno tiene su propio repositorio de subversión para cada uno de los componentes de sus productos. Lo que me gustaría hacer es tratar de reducir la dispersión que tenemos y ayudar a construir un camino claro hacia adelante.

Estoy buscando consejos sobre cómo estructurar los repositorios. Un punto difícil es cómo agrupar proyectos relacionados. Tenemos dos productos Cada producto tiene un conjunto de códigos de servicios web (php), código de cliente de Android (java), código de cliente de iphone (obj c), código de ipad (obj c) y código de cliente de sitio web (php + js). Actualmente cada propietario tiene su componente en un repositorio svn separado.

Mi idea era intentar combinar estos componentes en un repositorio, pero no puedo decir si es una buena práctica con git. ¿Esto proporciona algún beneficio real en lugar de tener repositorios separados? Parecería fomentar un mejor contrato social por la calidad de lo que se verifica debido a la visibilidad común, pero ¿vamos a pagar por eso de otras maneras?

Answer 1

Los criterios para la combinación de un conjunto diferente de archivos en un "componente" (en este caso uno de Git repo) es su respectivo ciclo de desarrollo (la forma en que evolucionan en términos de etiquetado y de ramificación):

• puede usted hace la evolución en el módulo php o java sin tener que hacer ninguna modificación a otros módulos (como los obj c ones)?
• ¿puedes aislar en una rama algunas evoluciones/correcciones que solo están hechas para una de esos módulos y no para los demás?
• ¿puede reutilizar una versión específica de uno de esos módulos en varios proyectos?

Si es así, un enfoque basado en componentes es mejor (es decir, un repositorio git por módulo), en contraposición a una cesión temporal con todo su contenido (system approach).
Ver por ejemplo "Component based web project directory layout with git and symlinks".

Un componente representa un "conjunto coherente de archivos" y se gestiona mejor en su propio repositorio de Git.

Answer 2

usted tiene por lo menos dos opciones:

• Submodules
• Subtree Merging

Si los proyectos son en su mayoría privadas, me gustaría recomendar que se pegue a la primera. Leer documentos, todo es fácil.

Answer 3

No sé mucho acerca de los flujos de trabajo Git pero sé que tiene al menos tres opciones:

1. Para cada proyecto de su propio repo, probablemente la opción más segura. Las etiquetas y las buenas herramientas de prueba son tus amigos.
2. Separa las ramas por grupo de proyecto y para cada proyecto su propia rama. Asegúrate de respaldar todo antes de hacer esto. Ver Scott Chacon's video en ramas vacías. No he hecho esto antes, pero las ramas de gh-páginas de Github son un ejemplo en vivo.
3. Submódulos. Cada proyecto tiene su propio repositorio git, dentro de un git repo ellos mismos. Probablemente la mejor idea.