¿Cuál es una forma práctica de mantener un parche secreto (de público) a un repository git?

Estoy haciendo una aplicación de demostración para una plataforma en particular (Jolla Sailfish) en github y va a tener algunos identificadores / keys que no quiero que el público vea. Por ejemplo, definitivamente no quiero que el público vea las keys reales de Mixpanel o Google Analytics. La versión pública debería tenerlos vacíos o usar keys completamente diferentes.

Dicho esto, cuando construyo la aplicación para mí, quiero que utilicen mis propias keys. Por lo tanto, quiero get un repository generalmente público, con una modificación mínima que se mantenga privada y secreta.

¿Cuál es una forma práctica de lograrlo?

Debería de alguna manera ser posible con la ayuda de submodules con uno de los submodules provenientes de mi repository privado (por ejemplo, de Bitbucket), pero de alguna manera no puedo entender todo lo que funcionaría tanto para el público como para mí.

¿Como lo harias? ¿O alguien ha tenido una situación similar en sus propios proyectos?

Lo que hice en mi file de puntos es tener una twig 'privada', ya que siempre especifico qué twigs presionar a cuáles controles remotos, nunca hay un problema.

Esto es lo que hice al final para https://github.com/amarchen/Wikipedia :

  1. El proyecto principal de git público tiene un submodule que apunta a un repository privado de git. Este submodule se registra en algo así como el directory "settings / AppStoreKeys"

  2. Si no tiene acceso al repository privado, el componente no podrá ser desprotegido y no tendrá ningún file dentro del subdirectory. El rest del repository público funcionará perfectamente sin errores de git o lo que sea. Es posible que los usuarios de terceros de su código ni siquiera noten que hay un submodule de configuration privada a less que use algunos otros componentes.

  3. Si tiene acceso al repository privado, busque el componente a través de "git submodule init" y "git submodule update". Eso crea tus files privados en la configuration / AppStoreKeys

  4. En time de ejecución, su código comtesting la existencia de files en la configuration / AppStoreKeys y lee la configuration desde allí o vuelve a un valor pnetworkingeterminado

Desventajas Para mis propósitos, funciona bien. Es una aplicación de demostración, simplemente no quiero que las personas que estudian el código usen en exceso las teclas de mixpanel de la aplicación real (y cualquier otra key). Tampoco me importa una posible necesidad de usar las otras teclas: es una aplicación de demostración, no para horquillas compatibles.

Sin embargo, este enfoque expone la dirección de mi repository privado a todos y eso no es muy bueno. Para los casos más serios, probablemente iría al revés y crearía un proyecto privado que sería solo un envoltorio (más keys privadas) para la biblioteca pública y tal vez un contenedor de aplicaciones públicas.