submodule git nested composer-php git-submodules git-subtree

GIT repositorios anidados: Compositor vs. SubModules vs. Subtree vs.



git subtree (1)

Finalmente, he incorporado la gestión de dependencias de GitHub y Composer en mi flujo de trabajo. Definitivamente es un gran paso adelante, aunque estoy muy confundido acerca de GIT que administra las dependencias "anidadas".

Cuando estoy usando una impresionante pila de Wordpress ROOTS / BEDROCK, mi estructura de directorios simplificada se ve así:

|-- /project | |-- /.git // git repository for the skeleton/stack of the project | |-- composer.json // list of dependencies, most of them are my own repositories on GitHub | |-- /vendor | | |-- /php-dependency-1 // 3rd party dependencies not directly related to Wordpress | |-- /web | | |-- /app // acts as "wp-admin" folder | | | |-- /mu-plugins | | | | |-- /SUBREPOSITORY-1 // my own framework feature, public, GitHub | | | | |-- /SUBREPOSITORY-2 // my own framework feature, public, GitHub | | | |-- /plugins | | | | |-- /SUBREPOSITORY-3 // my own plugin, public, GitHub | | | |-- /themes | | | | |-- /SUBREPOSITORY-5-PARENT-THEME // parent theme used on my framework, public, GitHub | | | | |-- /SUBREPOSITORY-6-CHILD-THEME // work for client, private, BitBucket | | |-- /wordpress // Wordpress CMS | | | |-- /wp-admin | | | |-- /wp-includes

Los "subrepositorios" se definen en mi composer.json en la raíz del proyecto y se descargan desde GitHub por la composer install . Hasta ahora tan bueno.

¡Pero! Espero modificar mucho mi parent-theme y algunos mu-plugins , necesito ser capaz de presionar / cometer desde cada uno de mis proyectos que serán incluidos. Como usted sabe, realmente no puede probar el tema de wordpress sin una instalación de wordpress ...

Entonces ... ¿qué camino tomar? Hay MUCHAS publicaciones sobre este tema y la mayoría de ellas mencionan los SubMódulos , pero si entiendo la idea de Compositor correctamente, están en conflicto entre ellos.

El uso de los repositorios .git anidados parece excelente para mi caso, aunque no parece funcionar. Si intento empujar / confirmar el repositorio anidado, o bien "todo está actualizado" o recibo mensajes como Your branch is ahead by 1 commit. ¿Tan solo "anidar" es un no ir?

Gracias de antemano y perdón por un poco de tono confuso de la pregunta, me ahogué un poco en el tema. :) Cualquier ayuda sería muy apreciada.

Tengo un par de preguntas, y en consideración a eso, la respuesta a continuación es bastante genérica. Si respondes a mis preguntas, con gusto lo actualizaré.

  1. ¿El compositor saca los repos en una actualización? O recone el repositorio? (¿Está haciendo actualizaciones?)

    • Si se vuelve a instalar, su uso para actualizaciones supondrá la posibilidad de sobrescribir su árbol de trabajo en esas subreposiciones ( utilícela SOLAMENTE para instalarlo o elimínelo todo junto )
    • Si no está haciendo actualizaciones (o recursión de dependencia, ver más abajo), entonces está agregando complejidad innecesaria a su proyecto ( elimínelo y use una de las opciones a continuación )

  2. ¿El compositor está haciendo realmente alguna gestión de dependencia (es decir, recurrente para encontrar dependencias anidadas)? ¿O es simplemente la clonación de los proyectos git como subcarpetas?

    • Si es así, entonces sí, los submódulos pueden ser inapropiados para su caso, ya que son un sistema de administración de dependencias alternativo, pero si sus subproyectos también administran sus dependencias con submódulos, entonces hacer un git clone --recursive debería funcionar también para gestionarlos.

  3. ¿Desea que su proyecto maestro haga un seguimiento de los nuevos cambios en sus subproyectos?

    • En caso afirmativo: eche un vistazo a la opción # 2: subrepositorios
    • de lo contrario: prueba la opción # 1: submódulos
    • [hay una tercera opción a la que enlazaré, pero no la he usado, así que no puedo explicarlo en detalle (se agradecen los comentarios / ediciones)]

Opción # 1: Submodules

También puede administrar un submódulo individual mediante el cd LOCAL_DIR_NAME_I y usando los comandos normales de git

  1. Configuración:

git submodule add REMOTE_URI_1 LOCAL_DIR_NAME_1 ... ... git submodule add REMOTE_URI_N LOCAL_DIR_NAME_N git commit -m "Add submodules..."

  1. Clonación (el proyecto principal)

    git clone MAIN_URI REPO && cd REPO && git submodule update --init --recursive

    --init copiará la configuración de .gitmodules a .git / config antes de realizar la actualización (si es necesario), y --recursive hará esa acción recursivamente en cada submódulo.

    o

    git clone --recursive MAIN_URI

    --recursive le dice a git que actualice e inicie todos los submódulos sobre la clonación

  2. Actualizando (conservará los cambios no guardados)

    • La copia local no tiene cambios no insertados (actualiza todos los submódulos de forma predeterminada):

    git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

    • La copia local tiene cambios no empujados (actualiza todos los submódulos de forma predeterminada):

    git submodule update --remote --rebase [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

  3. Publicación / Empujando

Esto intenta un empuje de submódulo primero y, si tiene éxito, ejecuta un empuje principal del proyecto

git push --recurse-submodules=on-demand

Opción # 2: Subrepositories

Usted ha dicho que tiene problemas con este método, pero no entiendo qué son. Por favor explique si es posible.

(El git book también habla de subrepos, pero no puedo por mi vida encontrar dónde, en este momento; avísame si lo encuentras)

  1. Configuración:

NOTA: el repositorio principal no rastreará los cambios en el .git de subrepo, solo en los archivos temaselves

La barra (/) después del nombre del directorio es esencial para evitar crear un submódulo

git clone REMOTE_URI_1 LOCAL_DIR_NAME_1 && git add LOCAL_DIR_NAME_1/ ... ... git clone REMOTE_URI_N LOCAL_DIR_NAME_N && git add LOCAL_DIR_NAME_N/ git commit -m "Add subrepos..."

Si usa Composer: (y está haciendo los clones por usted) puede simplemente hacer los agregados y confirmar, pero tal vez también puede configurar Composer para que haga esto.

  1. administración

Administra un subreprepto individual mediante: `cd LOCAL_DIR_NAME_N ''y usa los comandos normales de git

Recuerde que los cambios en sus archivos subrepo serán rastreados por su repositorio principal

El mayor problema aquí es con la clonación (si desea que los colaboradores puedan trabajar en los subproyectos), ya que no se realiza un seguimiento de los archivos .git de Subrepo. Incluyendo un archivo, remote.info en cada subpopo que almacena el control remoto debería resolver esto. Luego, agregue un script a su repositorio principal que haga para cada subdirectorio cd SUBDIR && git init && cat remote.info | xargs git remote add origin cd SUBDIR && git init && cat remote.info | xargs git remote add origin . Dependiendo de lo que esté haciendo Composer (consulte las preguntas anteriores) es posible que desee agregar un comando de composer update a este script

Opción # 3: fusión de subárbol

No estoy completamente seguro de las sutilezas de este método, así que solo lo vincularé

Prueba este enlace para un poco de tutorial.

Opción #N: Como quieras

Por supuesto, podría configurar muchos otros flujos de trabajo que en algunos casos podrían ser más simples. Por ejemplo, podría seguir con Composer para la gestión de dep y clonar sus subproyectos fuera de su proyecto principal, creando enlaces simbólicos sin seguimiento en el proyecto principal para permitir un acceso fácil a esos archivos cuando trabaje en el proyecto principal. Esto podría automatizarse con una secuencia de comandos (al igual que un envío por lotes de todos estos repositorios). Probablemente podría incluso analizar composer.json para hacer esto automáticamente para nuevas dependencias (basadas en git).

Nota: Me parece que no es necesario que uses Composer . Si esta suposición es incorrecta, es posible que ninguna de las 3 opciones anteriores solucione sus problemas.