Repositorios nesteds GIT: Compositor vs. Submodules vs. Subtree vs.

Finalmente, incorporé la administración de dependencies de GitHub y Composer en mi flujo de trabajo. Definitivamente es un gran paso adelante, aunque sigo muy confundido acerca de que GIT maneje las dependencies "anidadas".

Como estoy usando un impresionante WordPress Stack ROOTS / BEDROCK, mi estructura de directorys 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 

"Subrepositorys" se definen en mi composer.json en la raíz del proyecto y se descargan de GitHub mediante la composer install . Hasta aquí todo bien.

¡Pero! Espero ajustar mucho el parent-theme mis parent-theme y algunos mu-plugins , tengo que poder impulsar / comprometerme en cada uno de mis proyectos que se includeán. Como saben, realmente no se puede probar el tema de WordPress sin una installation de wordpress …

Entonces … ¿qué path tomar? Hay MUCHOS posts sobre este tema y la mayoría menciona submodules , pero si entiendo la idea de Composer correctamente, están en conflicto entre ellos.

Solo usar repositorys .git nesteds parece genial para mi caso, aunque parece que no funciona, si bash presionar / confirmar el repository nested, o bien "todo está actualizado" o recibo posts como Your branch is ahead by 1 commit. Entonces, solo "anidarlo" es un no a ir?

Gracias de antemano y disculpe un poco el 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 de eso, la respuesta a continuación es bastante genérica. Si responde mis preguntas, con gusto lo actualizaré.

  1. ¿El compositor saca los repos en una actualización? O reclone el repository? (¿Incluso está haciendo actualizaciones?)

    • Si vuelve a encenderse, usarlo para las actualizaciones correrá el riesgo de sobrescribir su tree de trabajo en esos subrepos (Úselo para instalarlo SOLAMENTE o elimínelo todo junto )
    • Si no está haciendo actualizaciones (o recursión de dependencies – ver a continuación), entonces está agregando complejidad innecesaria a su proyecto ( elimínelo y use una de las opciones a continuación )
  2. ¿El compositor realmente está haciendo alguna gestión de la dependencia (es decir, recurriendo para encontrar dependencies anidadas)? ¿O simplemente está clonando los proyectos de git como subcarpetas?

    • Si es así, entonces sí, los submodules pueden no ser apropiados para su caso, ya que son un sistema alternativo de administración de dependencies, pero si sus subproyectos también administran sus dependencies con submodules, entonces hacer un git clone --recursive debería funcionar para administrarlos también.
  3. ¿Desea que su proyecto maestro rastree nuevos cambios en sus subproyectos?

    • En caso afirmativo, eche un vistazo a la opción n. ° 2: subrepositorys
    • de lo contrario: testing la opción n. ° 1: submodules
    • [hay una tercera opción a la que me vincularé, pero no la he usado, así que no puedo explicar en detalle (los comentarios / ediciones fueron apreciados)]

Opción n. ° 1: Submodules

También puede administrar un submodule individual mediante cd LOCAL_DIR_NAME_I y usando los commands git normales

  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 copyrá la configuration de .gitmodules a .git / config antes de realizar la actualización (si es necesario), y --recursive hará esa acción recursivamente en cada submodule.

    o

    git clone --recursive MAIN_URI

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

  2. Actualización (preservará los cambios no guardados)

    • La copy local no tiene cambios sin presionar (actualiza todos los submodules por defecto):

    git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

    • La copy local tiene cambios sin presionar (actualiza todos los submodules por defecto):

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

  3. Publicando / Empujando

Esto intenta primero un empuje de submodule y si tiene éxito realiza un empuje de proyecto principal

git push --recurse-submodules=on-demand

Opción # 2: Subrepositorys

Has dicho que tienes problemas para usar este método, pero no entiendo cuáles son. Por favor elabore si es posible.

(el libro de git también habla de subrepos, pero no puedo por mi vida encontrar dónde, ahora, házmelo saber si lo encuentras)

  1. Configuración:

NOTA: el repository maestro no hará un seguimiento de los cambios al .git del subrepo, solo a los files mismos

La barra inclinada (/) después del nombre del directory es esencial para evitar la creación de un submodule

 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 usas Composer: (y está haciendo los clones para ti) simplemente puedes hacer los adds y commit, pero tal vez puedas configurar al compositor para que haga esto también.

  1. administración

Administre un subrep individual mediante: `cd LOCAL_DIR_NAME_N 'y use los commands normales de git

Recuerde que los cambios en sus files de subrepo serán rastreados por su repository principal

El mayor problema aquí es la clonación (si desea que los queueboradores puedan trabajar en los subproyectos) ya que no se realiza un seguimiento de los files .git de su subrepo. Incluir un file, remote.info en cada subrepo que almacena el control remoto debería resolver esto. A continuación, agregue una secuencia de commands a su repository principal que haga para cada subdirectory 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 command de composer update a este script

Opción # 3: fusión de subtree

No estoy completamente seguro de las sutilezas de este método, así que me limitaré a vincularlo

Pruebe este enlace para get un poco de un tutorial

Opción #N: de la forma que quieras

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

Nota: me parece que no necesita usar Composer en absoluto. Si esta suposition es incorrecta, es posible que ninguna de las 3 opciones anteriores resuelva sus problemas.