Git, sub-repos y libs externos para desarrollo web: ¿la mejor estrategia de una vez por todas?

Este es un escenario tan común que debe haber una solución sensata, sin embargo, a pesar de las páginas de lectura y la copiosa gimnasia de Git, me duele el cerebro y no puedo hacer que esto funcione …

Estoy trabajando con WordPress, aunque esto se ajustará a la mayoría de los escenarios de desarrollo de sitios web. Quiero administrar la installation del sitio con un git repo y también administrar varios plugins WP, plugins jQuery y otros bits de código en repositorys separados que pueden extraerse / empujarse fácilmente de sus fonts externas. Parece lo suficientemente simple hasta que mires los detalles …

El criterio

Criterio de "subcarpetas" La carpeta de cada complemento no debe vincularse a la carpeta raíz de su repository de origen. Muchos repos tienen múltiples carpetas anidadas, como "my-repo-name / …", "dev /", "test /", "src /", donde el contenido del último es lo que se necesita. Esto es importante para mantener limpias las URL de reference y minimizar la basura públicamente disponible.

Criterio "No Proxys" La solución ideal no requeriría sucursales intermedias o repositorys adicionales. La inserción de cambios en la fuente externa de un complemento debe ser simple y no requerir fusiones / fusiones intermedias múltiples.

Criterio de "files reales" Idealmente, el repository externo para todo el website debería contener los files de los subrepos de los complementos (es decir, no hay "submodules"). Podría ser persuadido lejos de este aunque …

Criterio de "publicación" Debe jugar bien con rsync y / o git push'ing para el server en vivo

He visto estas cinco soluciones

Submodules Git Lo suficientemente simple para realizar cambios y empujar / tirar, pero los submodules fallan en los criterios de "Subcarpetas" y "Archivo real"

Git read-tree / subreeree merge Resuelve el problema de "Real Files" y read-tree realmente te permite hacer reference a la subcarpeta de una twig, pero cuando lo hice e intenté fusionar los cambios en master backstream, Git no recordó que venía de una subcarpeta y fusionó toda la estructura del maestro en la twig de seguimiento de extensiones de expansión … por lo que FALLA en este criterio.

Extensión del subtree de Apenwarrs (aquí) Excelente para el criterio de "Archivos reales" y bastante simple para empujar / tirar hasta que desee aplicar la regla de "Subcarpetas". En el mejor de los casos, parece necesitar twigs intermedias donde se divide la carpeta que desea de la twig de seguimiento remoto y luego se agrega como un subtree a su twig principal. No tuve mucha suerte fusionando / empujando cambios en el maestro de nuevo al repository de origen. Sigo pensando que podría haber una posibilidad aquí …

Enlaces simbólicos con repo externo Gran solución hasta que GIT dejó de seguir enlaces simbólicos. Ahora falla en los criterios de "Archivos reales" y "Publicación"

Repositorios nesteds En algún lugar vi una respuesta SO, en la que si git add explícitamente una carpeta que contiene otro repository e incluye la barra al final, git NO lo submodulará, sino que rastreará los files individuales. Esto pareció prometedor pero falla en el criterio de "Subcarpetas".

¿Qué sigue?

He visto references a "checkout disperso", o tal vez algo relacionado con la poda de twigs. Espero evitar una solución que involucre scripts de shell o que sea tan compleja que requiera que vuelva a aprenderla cada vez (con poca frecuencia). Hago un cambio en un complemento. Debe ser más fácil que mantener un repository por separado para cada complemento y copyr hacia adelante y hacia atrás desde la installation principal del CMS.

¿Seguramente alguien tiene una forma funcional simple para hacer que este escenario de desarrollo común funcione? Gracias de antemano por la ayuda …

Claramente, has estado pensando en esto, y yo solo soy un novato en git, pero mi primer instinto sería agregar .gitignore al directory de complementos y hacer que cada complemento tenga su propio repository git. Podrías hacer lo mismo para los temas. Así que supongo que esto es más una pregunta que una respuesta: ¿por qué no funcionaría este simple enfoque?

No sé si esto responderá a su pregunta en su totalidad, o incluso cubrirá su escenario específico, pero pensé que lo probaría en cualquier caso.

Tenemos varios proyectos, muchos de los cuales se referencen entre sí, cada uno en su propio repository de Git. También están contenidos en múltiples niveles de carpetas, por ejemplo:

 Repos - Utilities - Util repo1 - Util repo2 - Common - Lib repo1 - Lib repo2 - Projects - Client1 - Git repo1 - Git repo2 - Client2 repo - Client3 ... 

Tuvimos un problema al tener que presionar manualmente / arrastrar / comprometer cada repository, lo que se convirtió en una pesadilla.

Así que escribimos un pequeño progtwig de utilidad que es capaz de realizar operaciones push, pull, commit, tag, remote diff y diff Git en múltiples carpetas a la vez, así como también crear múltiples files de solución VS al mismo time. También verificará las subcarpetas de los repositorys.

Lo hemos estado usando desde hace un time, y funciona bien para nosotros. Puedes verlo desde aquí: Gitter.7z

Abra el file ReadMe.html para ver cómo usarlo. Espero que esto ayude, házmelo saber.