Implementación solo cambió parte de un website con git a ftp (svn2web para git)

Tengo un website con muchos files de imágenes grandes. La fuente (así como las imágenes) se mantiene con git. Deseo implementar eso a través de ftp en un server barato similar a Bluehost.

No deseo desplegar todo el website cada vez (para que no tenga que cargar demasiados files sin modificar una y otra vez), sino para hacer más o less lo siguiente:

  1. En un repository de git, marque la última revisión desplegada con una label "desplegada".
  2. Cuando digo "implementar la revisión X", averigüe qué files han cambiado entre la revisión X y la revisión labeldos como implementación, y cárguelos solo a ellos.

Es similar en espíritu a svn2web . Pero quiero eso para DVCS. La alternativa mercurial será considerada.

Es un script bastante simple de escribir, pero prefiero no redevise la rueda si hay algún script similar en la web.

Capistrano y Fab parecen saber solo cómo impulsar toda la revisión, en su integración de SCM. Entonces no creo que pueda usarlos actualmente.

El script git-ftp puede ser lo que estás buscando. Toma los cambios del repository local de git y lo sincroniza con un repository remoto de git sobre ftp.

Lo utilicé alojando un repository git creado usando la opción –bare . Ponlo en mi server ftp.

que corrió ./git-ftp.py. Solicita el nombre de usuario ftp, la contraseña, el host ftp, la ruta de repository git local, la ruta remota git repo (la location del repository vacío).

Luego se conecta al ftp git repo y luego envía los diffs solo. (usa la biblioteca de git-python para get esa información).

La secuencia de commands tiene pocos problemas. Parece que siempre está pidiendo detalles de nombre de usuario y tuve que comentar la línea 68.

#ftp.voidcmd('SITE CHMOD 755 ' + node.name). 

Pero esas cosas se pueden arreglar fácilmente.

Alternativa

Si está en una plataforma de nix, una alternativa es usar curlftpfs . Montará su count ftp como un directory de dispositivo desde el que puede hacer todas las operaciones git normales (empujar, tirar). Por supuesto, esta solución no es específica de git.

Necesita usar la opción bare como se menciona arriba en el repository compartido en FTP así como ejecutar git update-server-info dentro del repository antes de compartirlo a través de FTP.

Precaución : esta no es una buena idea si planea tener varios usuarios para escribir en su git repo. Como FTP no tiene mecanismo para bloquear el acceso. Usted terminará con un repository corrupto. Prueba antes de llevar a producción.

Creé un script llamado git-deploy , espero que ayude.

Puede almacenar la última versión implementada en algún lugar de un file, luego simplemente puede get el nombre de los files modificados:

 $ git diff --name-only $deployed $latest 

Sustituya con los códigos Sha-1 de acuerdo, o $ latest puede ser "maestro", por ejemplo.

Otra opción sería usar el git archive .

Por supuesto, como lo menciona Joey en su " git archive como formatting de package de distribución ":

La parte difícil de usar un file git (u otro file rcs) como formatting de package de origen de distribución es el event handling files comprimidos primarios.

  • Un enfoque sería tratar de crear un file git que no incluyera objects presentes en el tarball ascendente. Luego, para descomprimir el package de origen, descomprimirías el file tar en sentido ascendente, convertirías los files en él en objects git y los agregarías al directory .git.
    Parece que podría ser posible implementarlo, pero necesitaría saber bastante acerca de git internals para eliminar los objects networkingundantes del repository git y regenerarlos del tarball.

  • Otro enfoque sería mantener el prístino tarball upstream en el file git, y luego el package fuente consistiría en su totalidad en el file git . Esto no tiene el mismo comportamiento de carga de ancho de banda mínimo agradable, a less que pueda " git push " sus cambios para realizar la carga

Almacenar un montón de tarballs en upstream en git no sería eficiente , pero el script prístino-tar se ocupa de eso:

prístino-alquitrán puede regenerar un tarball prístino aguas arriba utilizando solo un pequeño file delta binary y una copy de la fuente que puede ser una comprobación de control de revisión.
El package también incluye un command prístine-gz, que puede regenerar un file .gz prístino.
El file delta está diseñado para controlarse en el control de revisión junto con el código fuente, lo que permite extraer el tarball original del control de revisión.

Más detalles en el encabezado de esta secuencia de commands perl prístine-tar .

es muy posible que también use wput (wput –timestamping –reupload –dont-continue) – como wget solo para ftp uploading

Solución Tiny BASH para Mercurial: hg-deploy

El command git-ftp push de git-ftp parece funcionar bastante bien.

Instalarlo

 sudo apt-get install git-ftp 

Después de instalarlo, configure su count ftp

 git config git-ftp.url ftp.example.net git config git-ftp.user your-ftp-user git config git-ftp.password your-secr3t 

Entonces hazlo por primera vez

 git-ftp init 

Y luego, por cada cambio, solo necesitas

 git add -A git commit -m "update" git-ftp push 

Los files se cargarán en el directory de inicio del usuario ~/ .