¿Técnicas para manejar un repository privado y público?

Tengo un website de fuente abierta. Algunos contenidos son "privados", como los parameters de connection, así como los files que la versión de código abierto no necesita (por ejemplo, templates publicitarias).

Esencialmente estoy tratando de mantener dos versiones:

  • Un sitio público que tiene una identidad única (publicidad, count de Google Analytics, enlace para foro asociado, etc.)
  • Una versión de código abierto para el desarrollo de la comunidad, sin dependencies ni marcas innecesarias

Actualmente estoy usando un file .gitignore para evitar que el contenido "privado" se envíe al repository de código abierto. Junto con un asistente que incluye templates que se encuentran localmente, pero muestra un cuadro vacío para la versión de código abierto.

Esto funciona bastante bien hasta que bash pagar entre las twigs de características: una twig puede necesitar una nueva key en el file de configuration. Debido a que el file de configuration es ignorado por Git (para evitar el uso de passwords, etc.), el sitio se rompe.

Idealmente, me gustaría tener files de configuration de control de versiones, pero para poder decirle a Git que nunca empuje estos files a un server remoto (Github). ¿Es eso posible?

¿Debo usar sucursales para administrar diferentes versiones de sitios web?

Deberías usar los submodules de Git con:

  • un module para todo el contenido público, que puede ser empujado / tirado a voluntad
  • un module para el contenido privado
  • un superproyecto, también en un repository privado, que hace reference tanto a los submodules públicos como a los privados.

Las sucursales dentro de un repo no son la respuesta, especialmente cuando se trata de información sensible.

Sucursales (como sugirió), es probablemente la forma más directa de hacer esto. De hecho, esto es lo que se suponía que debían hacer, a saber, separar múltiples proyectos / versiones entre sí.