¿Cómo gestionar adecuadamente un repository git en un subdirectory, ignorado por el directory padre, como su propio proyecto?

Estoy buscando usar Vagrant para un proyecto de desarrollo para laravel . Para facilitar este esfuerzo, estoy usando este proyecto github , Laravel4-Vagrant .

La configuration vagabunda se gestiona como un repository git. Parte de la configuration de Vagrant tiene un directory www por definición que se asigna a /var/www una vez que el server está configurado para que pueda trabajar directamente con los files dentro de la vm de invitado desde la máquina virtual del host. Sin embargo, dentro de este directory www hay un file .gitignore . Esto tiene mucho sentido porque desea administrar su configuration vagabunda y comenzar de cero con el desarrollo de su aplicación, etc.

Sin embargo, empiezas a hacer tu desarrollo de aplicaciones y tienes tu proyecto sentado en este directory de www . También sería bueno administrar este proyecto en git, luego podría implementar su aplicación en otro server web o en una nueva installation vagabunda. Debido al file .gitignore , no hay forma de usar git en los files en este directory ya que el padre quiere ignorarlo.

No estoy seguro si git-submodules es la solución correcta aquí o alguna otra configuration especial.


Más genéricamente:

¿Cómo puedo crear un repository git para un proyecto, que ignora un directory secundario, pero los files dentro de ese directory secundario (que son ignorados por el padre) se administran en su propio repository git?

Idealmente, debería ser capaz de empaquetar el padre y el hijo por separado.

Agradecería una explicación genérica y alguna ayuda específica para configurar el proyecto mencionado anteriormente como ejemplo.


Ediciones:

No existe un requisito real para la estructura, etc. siempre que los dos proyectos se puedan mantener en repositorys separados y se puedan implementar juntos o uno por su count (por ejemplo, puedo usar mi vagrant personalizado para configurar otro entorno dev / prod o puede implementar el proyecto laravel en una implementación existente en otro lugar). También consideraría otros sistemas de control de versiones fuente estándar que funcionen fácilmente juntos. Además, ¿haría una diferencia si el repository de laravel inicial se instalara a través de git? utilizando el proyecto de plantilla github citado anteriormente, no clona un repository git para la installation inicial, sino que utiliza el instalador laravel.

Desde la raíz del proyecto, con un índice limpio:

  1. git rm www/.gitignore
  2. Agregue / www a su .gitignore en la raíz del proyecto. Bien podría deshacerse de estas líneas mientras lo hace:

     /www/bootstrap/compiled.php /www/vendor 
  3. git add .gitignore

  4. git commit

… y eso debería hacerlo. Ahora puede ejecutar los commands git que desee dentro de www sin interferir con el repository externo. Ambos repos pueden ser clonados por separado, aunque la configuration vagabunda no debería funcionar a less que el repository interno esté clonado en el lugar correcto, por supuesto.

Los submodules de Git son, desde el punto de vista de sus repositorys, un "enlace" a otro repository. Los casos de uso includeían dependencies que se desarrollan fuera de su proyecto. Personalmente no lo usaría para separar su proyecto de su configuration vagabunda.

Tengo dos forms en las que generalmente configuro proyectos con vagrant. Pueden servir como una guía para que usted decida qué va a hacer.

Pon la configuration vagabunda dentro de tu proyecto

Cuando uso un vm que está vinculado exactamente a un proyecto, estoy poniendo el Vagrantfile y los libros de cocina junto con todos los files src en un repository de git.

La estructura de la carpeta del repository puede verse así:

 myProject/src/ myProject/vm/ 

Dentro de vm , uno puede encontrar el Vagrantfile , la carpeta .vagrant (ignorada por git) y los files de provisión. Dentro del src . Puse todo lo que normalmente viviría en la raíz del repository.

Esta configuration es útil si la vm está estrechamente acoplada al proyecto. La vm no necesita ser utilizada si alguien elige no hacerlo, pero está ahí. Al dividir los directorys, uno puede filtrar el logging de git por directory y tener un logging "limpio" de cambios en el proyecto y en la versión mobile si es necesario.

Un inconveniente sería que los files ocupan un poco más de espacio en la HD, pero como solo son text y generalmente no mucho, esto realmente no count.

Por supuesto, puede poner el Vagrantfile en su raíz de repository junto con la configuration normal del proyecto y tener una carpeta para sus files de provisión.

Tener un repository vm y repositorys de proyectos

Para esta configuration, la VM única tiene su propio repository. El Vagrantfile apunta a lugares en el sistema host para carpetas sincronizadas.

 VM --> vm/project-a --> dev-machine/project-a --> vm/project-b --> dev-machine/project-b --> vm/project-c --> dev-machine/project-c 

Las carpetas del sistema host pueden no estar allí si el usuario no ha clonado esos proyectos. También podría suceder que el usuario no actualice los repositorys del proyecto. Entonces recibirán errores porque los cambios en un proyecto rompen la máquina virtual.

Usamos esta configuration en una compañía donde teníamos muchos proyectos diferentes que se ejecutaban en un grupo de serveres idénticos. Entonces, necesitábamos solo una máquina virtual para ejecutar todos esos proyectos.

Después de un corto time, todo el mundo estaba acostumbrado a actualizar la VM si ocurrían errores. También verificamos un Vagrantfile.dist en el repository. Los desarrolladores tuvieron que copyrlo y crear su propio file Vagrant local. Cambiarían las carpetas sincronizadas para señalar las routes reales del proyecto en su host. Además, tendrían que eliminar proyectos con los que no estaban trabajando.

Hubiera sido mucho peor si creáramos una máquina virtual para cada proyecto. O envíe el VM como un único proyecto y pida a todos que lo revisen y desarrollen con ese proyecto.