¿Cómo gestionas repositorys git de tercera persona en tu proyecto? (por ejemplo, Twig / Assetic / ..)

Hice un marco personal ligero en PHP que coincide con mis necesidades de un marco. Estoy usando diferentes bibliotecas de terceros, como SwiftMailer, Twig, Assetic, Facebook PHP api, …

¿Cómo gestiona estos códigos de fonts de bibliotecas de terceros? ¿Lo agregas como un submodule en tu proyecto y solo haces un pull para get la última versión? ¿O simplemente copy el código en su directory de proyecto y realiza las actualizaciones usted mismo?

La mayoría de los repositorys de código están estructurados de esta manera:

  • documentos
  • src
  • testings

Por lo tanto, en mi directory de frameworks se ve así, y nosotros los directorys de proveedores como submodules de un proyecto remoto:

  • documentos
  • src
    • vendedor
      • Assetic (clon del repository remoto)
      • src
  • testings

¿Es este el path a seguir? ¿O cómo sugieres hacer esto? Durante una implementación de Capistrano, todos los repositorys de submodules se extraerán de los serveres remotos.

Editar: Debo decir que utilizo el marco como submodule en otros proyectos. Entonces, el framework es un submodule en un proyecto, y el framework también tiene submodules en él.

¡Gracias!

Generalmente utilizo una carpeta de vendor , ya sea de nivel superior o bajo src o lib que contiene los submodules, y uso la opción --recurse-submodules when pulling, y --recursive con la git submodule update git submodule status y el git submodule status . Creo que Capistrano puede manejar este caso de uso decentemente, pero no estoy lo suficientemente familiar como para saberlo con certeza.

Administro cada proyecto separetaly. Cada carpeta de proyecto puede contener todos los files para una compilation correcta, por lo que todos los files a los que se hace reference se incluyen en el directory "refs". En este caso, es fácil de comstackr: obtenga la última versión del directory "src, refs & build", ejecute el script de compilation. La salida está en el directory "bin".

La carpeta "refs" está consumiendo el tamaño del disco, pero es mucho más simple que administrar references entre proyectos con versiones de corrección (y sucursales).

  • 3rdParty-Project-A
  • 3rdParty-Project-B
    • src // código fuente y resources
    • refs // binarys referencedos en la versión correcta
    • compilation // script de compilation
    • bin // binarys construidos y files relacionados
    • implementar // files utilizados para implementar (setup.exe, setup.msi, etc.)
    • … otras carpetas …
  • MyProject-A
  • MyProject-B
    • src
    • refs
      • 3rdParty-Project-B // hay files de reference de 3rdParty-Project-B
      • MyProject-A // hay files referencedos de MyProject-A
    • build
    • compartimiento
    • desplegar
    Intereting Posts