submodules - git subtree

Git, sub-repos y librerías externas para desarrollo web: ¿la mejor estrategia de una vez por todas?

Question

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 de la gimnasia Git abundante, 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 instalación del sitio con un repositorio de git y también administrar varios complementos de WP, complementos de jQuery y otros bits de código en repositorios separados que pueden extraerse fácilmente de sus fuentes externas. Parece bastante simple hasta que miras los detalles ...

El criterio

Criterio de "subcarpetas" La carpeta para cada complemento no debe estar vinculada a la carpeta raíz de su repositorio de origen. Muchos repositorios tienen múltiples carpetas anidadas como "my-repo-name / ...", "dev /", "test /", "src /" donde el contenido de este último es lo que se requiere. Esto es importante para mantener las URL de referencia limpias y para minimizar la basura pública.

Criterio de "No Proxys" La solución ideal no requeriría sucursales o repos intermedias adicionales. Presionar los cambios a la fuente externa de un complemento debería ser simple y no requerir múltiples combinaciones / presiones intermedias.

Criterio de "archivos reales" Idealmente, el repositorio externo de todo el sitio web debería contener los archivos de los subrepos de los complementos (es decir, no "submódulos"). Podría ser persuadido lejos de este sin embargo ...

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

He mirado estas cinco soluciones.

Submódulos de Git Lo suficientemente simple para hacer cambios y empujar / jalar, pero los submódulos fallan en los criterios de "Subcarpetas" y "Archivo real"

Git read-tree / subtree merge Resuelve el problema de "Archivos Reales" y read-tree realmente te permite hacer referencia a la subcarpeta de una rama, pero cuando lo hice e intenté fusionar los cambios en el maestro en sentido ascendente, Git no recordó que provenía de una subcarpeta y fusionó toda la estructura del maestro en la rama de seguimiento de librerías externas ... así que FALLA en este criterio.

Extensión de subárbol de Apenwarrs (here) Excelente para el criterio de "Archivos reales" y bastante fácil de presionar / tirar hasta que quiera aplicar la regla de "Subcarpetas". En el mejor de los casos, parece que se requieren sucursales intermedias en las que se divide la carpeta que desea de la sucursal de seguimiento remoto y luego se agrega como un subárbol a su sucursal maestra. No tuve mucha suerte al fusionar / empujar los cambios en el master al repositorio de origen. Todavía creo que podría haber posibilidades aquí ...

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

Reposiciones anidadas En algún lugar vi una respuesta de SO donde, si explícitamente git add una carpeta que contiene otro repositorio e incluye la barra diagonal, no la submodulará sino que rastreará los archivos individuales. Esto parecía prometedor pero falla en el criterio de "Subcarpetas".

¿Qué sigue?

He visto referencias a "desprotección dispersa", o tal vez a algo relacionado con la poda de ramas. Espero evitar una solución que implique shell scripts o que sea tan compleja que requiera que la vuelva a aprender cada vez (poco frecuente). Realizo un cambio en un complemento. Debe ser más fácil que mantener un repositorio por separado para cada complemento y copiar desde la instalación principal de CMS.

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

Answer 1

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

Answer 2

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

Tenemos múltiples proyectos, muchos de los cuales se hacen referencia entre sí, cada uno en su propio repositorio 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 con tener que empujar / tirar / cometer manualmente cada repositorio, lo que se convirtió en una pesadilla.

Así que escribimos un pequeño programa de utilidad que puede realizar operaciones Git push, pull, commit, tag, diff remoto y diff en múltiples carpetas a la vez, así como crear múltiples archivos de soluciones VS al mismo tiempo. También verificará en las subcarpetas para repositorios.

Lo hemos estado utilizando desde hace algún tiempo y funciona bien para nosotros. Puedes comprobarlo desde aquí: Gitter.7z

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