Un tree de trabajo, administrado conjuntamente por varios repositorys?

Me pregunto si hay una forma de controlar la versión de un tree de directorys conjuntamente entre varios (al less 3) repositorys Git .

Aquí hay una versión simplificada de mi tree de directorys. En la vida real, es el directory de service web para un website de Drupal o Joomla .

root/ index.php # code, managed by application repository configuration.php # secrets, eg database password uploads/ # contains user-supplied data temp/ # directory of temporary files, not archived attack.php # attack code or data, unwanted, should be detected 

index.php representa el código de mi aplicación web. Solo los desarrolladores contribuyen a eso. Queremos que sea controlado por la versión. Queremos confiar en Git para su implementación en los serveres de producción y puesta en escena.

configuration.php representa la configuration de la aplicación web como implementada. Contiene valores que difieren entre las versiones y las versiones de testing de la aplicación, por ejemplo, el nombre de la database que la aplicación debe usar. También contiene valores que son secretos, por ejemplo, la contraseña de la database. No quiero esos secretos en el repository de la aplicación. En cambio, el repository de la aplicación tiene una copy de marcador de position de este file, con valores inocuos. Creo que quiero un segundo repository, alojado en el server pero con distribución limitada, para administrar este file.

uploads/ representa files y treees de directorys, que contienen datos proporcionados por el usuario: sus publicaciones de blog, sus imágenes, sus files compartidos. Estos files no se deben agregar al repository de la aplicación. Sin embargo, me gustaría tener un repository separado de datos proporcionados por el usuario para rastrearlos. Podría respaldarlos, podría usar el repository para moverlos a un server diferente. Quiero observar si un atacante agrega files, por ejemplo, con extensiones de nombre de file inesperadas, a este directory.

tmp/ representa un directory de files temporales generados por la aplicación, ya que maneja la actividad del usuario. Puede ser un caching. No quiero estos files en ningún control de versión. Sin embargo, sí quiero observar si un atacante agrega files, por ejemplo, con extensiones de nombre de file inesperadas, a este directory.

attack.php representa tanto los files nuevos como los cambios en los files de la aplicación, que son agregados por un atacante malicioso. Quiero ser capaz de detectar que estos han aparecido. git status es excelente para esto, si el repository tiene el contenido correcto.

Es fácil para mí ver cómo administrar este tree de directorys con un único repository de aplicaciones. configurar este tree de directorys con un dir git en otro lugar. Puedo rociar '.gitignore' alnetworkingedor, digamos, para ignorar el contenido de las uploads/ y tmp/ . Puedo hacer que el repository de aplicaciones ignore configuration.php .

No veo cómo configurar un segundo repository para administrar configuration.php , y sobrescribir los valores inocuos en la copy del repository de la aplicación. No veo cómo configurar .gitignore que le indicará al repository de la aplicación que mire index.php e ignore las uploads/ , mientras le dice al repository de datos del usuario que haga lo contrario.

El obstáculo subyacente parece ser que Git supone que el tree de trabajo pertenece a un único repository, y estoy tratando de get múltiples repositorys para compartirlo. Entonces, ¿hay alguna manera de compartir esto, prácticamente, con Git?

Pregunta Varios repositorys en un directory son similares. Creo que alguien dice que esto se puede hacer con Subversion . No veo ninguna de las respuestas que dicen que se puede hacer con Git. Especialmente, una respuesta que señala que puede especificar los --git-dir y --working-tree en muchos commands de Git, no habla de cómo manejar las diferentes necesidades de .gitignore .

Pregunta ¿Es posible gestionar múltiples repositorys de forma coherente? tiene una respuesta que menciona a Repo , que a su vez menciona a Gerrit . Eso es interesante, pero ¿alguien lo usó para establecer una estructura como la que yo busco?

Una alternativa a rociar los files .gitignore en el tree de trabajo es listr las routes en el file $GIT-DIR/info/exclude para cada repository. Esto permite que cada repository ignore lo que quiere ignorar. Pero me preocupa que los contenidos de estos files de exclude no se controlen por sí mismos, y es posible que no se transmitan a los desarrolladores que están trabajando en la aplicación en sus propios repositorys.

¿Qué enfoque recomiendas?

La sum del repository múltiple en un repository principal es el trabajo que se realiza mejor al:

  • submodules (como se explica aquí )
  • o subtree ( ilustrado allí )

Para un file con datos confidenciales o específicos del entorno, debe usar un controller de filter de contenido (vea esta respuesta ) que, al finalizar la compra, generará automáticamente el file con el contenido apropiado.