Tengo un proyecto alojado en github con la siguiente estructura
github.com/example/allpackages
. ├── .git └── packages ├── example-1 ├── example-2 └── example-3
En cada envío a github, me gustaría que los contenidos de cada package se envíen a un repository que corresponde al nombre del repository, por ejemplo:
github.com/example/example1
. ├── .git └── example1
github.com/example/example2
. ├── .git └── example2
etc.
¿Alguien tiene alguna idea sobre cómo automatizar esto? Alguien mencionó el uso de Travis-CI para esta tarea, pero no pude encontrar ningún detalle sobre cómo podría funcionar.
Mi solución ideal:
Cualquier orientación sobre dónde comenzar a investigar sería muy apreciada. ¡Gracias por adelantado!
Editar:
@VonC sugirió usar submodules y hacer commits usando git submodule foreach --recursive
Pros:
git submodule foreach --recursive usando un alias permite una única confirmación a múltiples submodules Contras:
git submodule foreach --recursive es engorroso y no tan elegante como una confirmación normal. Para este caso de uso particular. Los repos de "packages", por ejemplo, github.com/example/example1 , solo se leerán en un sentido. No los presionaré directamente. Solo recibirán actualizaciones cuando se actualicen todos los allpackages . La única razón por la que deben crearse es porque el administrador de packages que los utiliza requiere repos separados para cada package.
Si declara todas sus carpetas exampleX como repository git, y las convierte en submodules de los repos repos allpackages , entonces:
cada repository exampleX puede tener su propio repository upstream en GitHub
( desde git 1.7.11 ), puede presionar everyhting a sus respectivos repositorys
cd allpackages git push --recurse-submodules=on-demand
Un command, y todo está empujado.
Github no ejecutará los ganchos de repo. La configuration de un repository proxy de github con un gancho post-actualización que adapta el seguimiento automático en esta respuesta y luego reenvía los empujones, a medida que lo leo, satisface los requisitos establecidos.
Dicho eso, sin embargo, estoy con VonC. Si no va con submodules va a estar atascado con algo así, y en realidad, no es más que un submodule frágil, tullido y sigiloso que solo funciona para ese repository, y que se romperá tan pronto como alguien lo presione. en cualquier lugar less a ese proxy. Puede ser muy conveniente para su propio trabajo, en un repository privado, y hay forms de eliminar la fragilidad un paso más adelante, pero para una disciplina compartida, no es lo suficientemente robusto.
Para el trabajo compartido apostaría a que tarde o temprano terminarás cambiando a submodules y descubrirás que no son muy misteriosos. Así que ignóralo y acepta la respuesta de VonC 🙂
Todavía prefiero el enfoque limpio de "submodule" que recomendé antes .
Pero otra forma más tediosa de enviar una carpeta de un repos a un repository upstream independiente sería utilizar la técnica de repos repo .
cd myrepos git clone https://github.com/example/example1 git clone https://github.com/example/allpackages cd allpackages/packages/example-1 git --git-dir=../../../example1/.git add . git --git-dir=../../../example1/.git commit -m "commit for example1" git --git-dir=../../../example1/.git push
Eso consideraría, para el allpackages/packages/example-1 repo de GitHub, el tree de trabajo de allpackages/packages/example-1 : --git-dir hace que Git crea que allpackages/packages/example-1 es un repository de git (nested) propio, con un ' origin ' remoto que hace reference a GitHub.
Pero : eso significaría 3 commands push diferentes, a less que ajuste esos commands en un script y llame a esos scripts a través de un git alias :
git config alias.pushall '!sh pushall.sh'