¿La mejor práctica para gestionar las variantes de proyectos en Git?

Question

Tengo que desarrollar dos proyectos de Django que comparten el 90% del mismo código, pero tienen algunas variaciones en varias aplicaciones, plantillas y dentro del mismo modelo.

Estoy usando Git para control de origen distribuido.

Mis requisitos son que:

• código común para ambos proyectos se desarrolla en un solo lugar (entorno de desarrollo de Proyecto1)

• periódicamente esta se combina en el entorno de desarrollo del segundo proyecto (Project2)

• las variaciones no se encapsulan fácilmente dentro de las aplicaciones. (Por ejemplo. Hay aplicaciones. Tales como "perfiles" que varían entre Proyecto1 y Project2 pero para los que también hay una evolución común en curso)

• tanto Proyecto1 y Project2 tienen repositorios públicos, de modo que pueda colaborar con otros

• similarmente Project1 y Project2 deberían tener servidores de desarrollo, demostración, almacenamiento en etapas y producción.

• sin embargo, el repositorio público no está en el mismo servidor en ambos casos. Entonces, por ejemplo, cuando estoy desarrollando en Project1, quiero poder "empujar" a mi servidor github, pero no tengo material de Project2 yendo allí.

• hay archivos tales como local_settings.py cuales son completamente diferentes entre Proyecto1 y Project2, pero deben compartirse entre varios desarrolladores de cada Proyecto

Entonces, ¿cuál es la mejor manera de manejar esta situación?

Lo que parece ser ideal sería algo así como un "tirón filtrado" donde en lugar de .gitignore diciendo "ignore este archivo por completo", puedo decir "ignore este archivo cuando saque de ese informe" No pude ver algo así en la documentación, pero ¿podría haber algo como eso?

Answer 1

Haría un tercer repositorio donde colocaría el código que comparten los proyectos. Entonces Project1 y Project2 tendrían su propio repositorio y pueden sacar de ese tercer repositorio "compartido".

Creo que su idea de "extracción filtrada" dificultará su mantenimiento.

Answer 2

Mueva el código común a su propia biblioteca y conviértalo en una dependencia de esos dos proyectos. No se trata de control de versiones, sino de reutilización de códigos, diseño y eliminación de duplicaciones.

Answer 3

me gustaría probar submódulos: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules

Answer 4

Teniendo en cuenta que es un sitio Django/Pinax, con variantes repartidos por todo el interior de varias aplicaciones diferentes, yo no recomendaría el uso de submódulos.

Las variantes se deben gestionar de forma independiente en las ramas project1 y project2, eliminando la necesidad de "filtrar" un resultado de gitignore.

Si identifica algunos códigos muy comunes, que puede terminar en una tercera cesión temporal que podría entonces "subárbol fusionado" a Project1 y Project2 repositorios (el significado de ser la estrategia de combinación de subárbol illustrated in this SO answer)

Answer 5

Se pueden utilizar dos diferentes ramas de git para el desarrollo. Cuando hagas cambios en uno que sea común para el otro, simplemente git-cherrypick ellos. También puede empujar y tirar de ramas específicas para que nadie sepa que está trabajando en las dos al mismo tiempo.