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

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

Estoy usando Git para control de fuente distribuido.

Mis requisitos son que:

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

  • periódicamente esto se fusiona en el entorno de desarrollo del segundo proyecto (Proyecto2)

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

  • tanto Project1 como Project2 tienen repositorys públicos, por lo que puedo queueborar con otros

  • de forma similar, Project1 y Project2 deberían tener serveres de desarrollo, demostración, puesta en escena y producción.

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

  • hay files como local_settings.py que son completamente diferentes entre Project1 y Project2, pero deben ser compartidos entre múltiples desarrolladores de cada proyecto.

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

Lo que parecería ser ideal sería algo así como un "tirón filtrado" donde en lugar de .gitignore diciendo "ignorar este file por completo", puedo decir "ignorar este file cuando salga de ese informe". No pude ver nada así. en la documentation, pero ¿podría haber algo como eso?

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, layout y eliminación de duplicaciones.

Teniendo en count que es un sitio de Django / Pinax, con variantes dispersas en varias aplicaciones diferentes, no recomendaría el uso de submodules.

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

Si identifica algunos códigos realmente comunes, pueden terminar en un tercer repository, entonces podría "subtree fusionado" a repositorys project1 y project2 (el significado de la estrategia de fusión de subtreees se ilustra en esta respuesta SO )

Puedes usar dos twigs diferentes 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 twigs específicas para que nadie sepa que está trabajando en las dos al mismo time.

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

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