tipos - git ver archivos modificados

Copie automáticamente los archivos enviados desde un repositorio de GitHub a otro

Question

Tengo dos repositorios de GitHub.

Me gustaría automáticamente (y probablemente usar ganchos y / o API de github) enviar y enviar archivos al segundo repositorio cuando se envíen al primero.

El segundo repositorio no es un clon del primero, su diseño de carpeta no es necesariamente el mismo, solo hay un montón de archivos en común.

¿Cuál es la forma más sencilla de hacer esto?

Puntos de bonificación si no tengo que instalar un servidor http o aprender perl :)

Answer 1

Como tiene un repositorio diferente, puede intentar aplicar las confirmaciones una por una utilizando git-apply / git-am y luego presione.

Suponiendo que tiene Repo1.git y Repo2 en un servidor, Repo1.git es el repositorio simple, Repo2 es un clon local de su segundo repositorio.

Repo1/.git/hooks/post-receive
#!/bin/sh
t=$(mktemp)
repo2_directory=/some/place/you/cloned/repo2
error=
while read line; do
ref1=$(echo "$line"|cut -d'' '' -f1)
ref2=$(echo "$line"|cut -d'' '' -f2)
for ref in $(git log --oneline $ref1..$ref2); do
git show -p --no-color --binary $ref > $t
if !(cd $repo2_directory && git am -q < $t || (git am --abort; false)); then
echo "Cannot apply $ref" >&2
error=1
break
fi
done
[ -n "$error" ] && break
done
rm -f $t
[ -z "$error" ] && (cd $repo2_directory && git push)

Answer 2

Dos repositorios de GitHub solos (sin que un servidor de terceros escuche los eventos de webhook) no pueden duplicarse entre sí.

Necesitaría registrar un webhook en un repositorio de GitHub para detectar el evento push, y pasar al segundo repositorio de GitHub.

Eso significa tener un servidor que escuche la carga útil de webhook json .

Una herramienta como dustin/gitmirror puede ayudar (en Go).

Answer 3

Si está buscando algo robusto y fácil de mantener, lo invito a que desarrolle una solución en torno a GitHub Webhooks . Sí, requerirá que implemente un servidor HTTP, digamos un servidor Node.js , y requerirá una pequeña cantidad de desarrollo (sus requisitos son bastante específicos), pero creo que será rentable si necesita algo confiable y bajo. -mantenimiento. Eso es si decide que este enfoque de duplicación de archivos sigue siendo lo correcto, después de haber considerado los enfoques y el esfuerzo de configuración.

Deje que los repositorios de origen (en GitHub) sean S1 , S2 ... con conjuntos de archivos (no superpuestos) para reflejar F1 , F2 ..., que se enviarán a un repositorio de destino T (también en GitHub), donde los archivos se consideran de solo lectura. Sus requisitos son inusuales en el sentido de que Sn y T suenan como si no estuvieran clonados entre sí, es posible que ni siquiera tengan un compromiso común, en cuyo caso este no es un escenario push / fetch. Tampoco ha garantizado que las actualizaciones de los archivos de origen se produzcan una vez por confirmación, o incluso que estén agrupadas pero aisladas de los cambios que no se replican, por lo que no se trata de confirmaciones de selección de cereza.

El desencadenante para la replicación es el envío de ciertos archivos a S1 , S2 ..., no una confirmación en ningún clon de desarrollador de esos repos, por lo que los enganches del lado del cliente no ayudarán (y pueden ser difíciles de mantener). Por supuesto, GitHub no permite enlaces genéricos, por lo que los Webhooks son su mejor solución. Podría considerar otro clon de sondeo que se extrae regularmente de S1 ..., realizar la lógica y luego comprometerse con T, pero esto suena incómodo en comparación con los Webhooks, que le brindarán una entrega confiable, capacidad de repetición, una pista de auditoría decente, etc.

La ventaja es que hay una gran cantidad de infraestructura ya construida para soportar este tipo de configuración, por lo que el código real que tendría que escribir podría ser bastante pequeño. Digamos que vas con una configuración de tipo Node.js :

• Despliegue github-webhook-handler . Esta pequeña biblioteca es un manejador pre-creado para GitHub Webhooks, y maneja la verificación HMAC X-Hub-Signature y proporciona enlaces simples para escuchar a todos los eventos de Webhooks. Podría tener un punto final por S, o probablemente sea más fácil abanicarlos.
• Tenga algún archivo local (guárdelo en un repositorio de Git) que asigne Sn a Fn .
• Registre un controlador para X-GitHub-Event: push e inspeccione el repository/name y commits[]/modified[] para ver las rutas que coincidan con su mapa local.
• Despliegue node-github , una implementación de GitHub APIv3 para Node.js.
• Para cada archivo coincidente:
  • Llame a getBlob para leer una copia del archivo utf-8 o base64 de Sn.
  • Llame a createBlob para volver a crear ese archivo en T
  • Haga una serie de llamadas a T para getReference (confirmación actual), getTree , getTree (crear una nueva desde la base y el nuevo blob), createCommit y finalmente updateReference . Ese es un flujo de trabajo, uno de menor colisión sería ramificar / fusionar.

Este enfoque le permite hacer todo sin necesidad de un clon local de T Tal vez le resulte mejor usar un clon local, vería qué fácil es usar el método API primero.

Answer 4

Tuvimos un problema similar: queríamos copiar automáticamente los archivos de documentación entre los repositorios del proyecto y los de la documentación común. Hemos creado una herramienta que escucha los webhooks de GitHub, analiza los compromisos y crea una solicitud de extracción a un destino elegido. Lo hemos abierto, https://github.com/livechat/copycat , se puede utilizar en cualquier servidor de plataforma de nodo.

Answer 5

Una forma sencilla de hacer esto es agregar dos (o más) pushurl s al origin (o algún otro control remoto).

Por ejemplo:

git remote set-url --add --push origin url1
git remote set-url --add --push origin url2

No cambia mucho el flujo de trabajo de nadie, pero todos los impulsos se duplican de manera efectiva para ambos repositorios. Se explica con mucho más detalle here .

Si hay muchas personas trabajando en el mismo repositorio y desea que se reflejen sus cambios, intente ejecutar un script para asignar los nuevos pushurl para cada desarrollador. De lo contrario, me temo que necesitarás usar hooks + server.

Answer 6

EDIT : Ahora me doy cuenta de que la pregunta era acerca de GitHub. Mi respuesta es sobre un repositorio git estándar al que tiene acceso a archivos.

Supongo que el segundo repo es un clon del primero, creado algo como esto

git clone --bare first.git second.git

Cambie el directorio actual a dentro del repositorio de first.git , y agregue el second.git como un control remoto.

cd first.git
git remote add second ../second.git

Luego, cree un archivo en la carpeta first.git/hooks/ named post-receive (puede cambiar el nombre del archivo post-receive.sample que ya existe)

El contenido debe ser este

#!/bin/sh
git push second

Ahora, cuando presiona nuevas confirmaciones en el primer repositorio, se ejecutará inmediatamente una inserción de la primera a la segunda, de modo que también la segunda recibe las confirmaciones.