¿Importar el historial de revisión de documentos de Google Docs en un repositorio de Git?

16

Me gustaría ver el historial de revisiones de un documento de Google Docs utilizando herramientas más flexibles como Git, y posiblemente migrar parte del contenido de Google Docs a un proyecto de Git.

Google Docs tiene una API con acceso al historial de revisiones, por lo que esto debería ser posible para cualquiera de los diversos formatos de exportación que admite. Sin embargo, noto que ha habido algunos problemas de API con el historial de revisiones que significan que la lista de contribuyentes a cada revisión puede no estar completa, aunque están considerando arreglar eso:

A veces hay más de un editor (para una revisión particular). Sin embargo, la API siempre me da un editor por revisión.

¿Hay algún código o consejo sobre cómo hacer esto disponible? Exportar a un sistema de control de versiones diferente como bzr, Mercurial, SVN o CVS también sería de interés.

Esto está relacionado con el control de versiones de la pregunta de desbordamiento de pila con las mejores prácticas de Google Docs. , que estaba cerrado como fuera de tema allí.

google-drive

— nealmcb
fuente

10

Lars Kellog-Stedman creó una pequeña aplicación de Python llamada gitdriver que encontré en esta respuesta en StackOverflow . Hace lo que estás buscando. Se autentica en Google con OAuth y despliega todas las revisiones de un documento, enviándolas a un repositorio git.

Con esto, puede obtener una copia versionada de su Google Doc y luego trabajar con ella utilizando las herramientas tradicionales de git.

— gene_wood
fuente

5

El Revisionator es otro sistema de documentos en línea (como Google Docs) pero con control de revisión incorporado. Se asemeja a herramientas más flexibles como git, ya que tiene soporte para diferir, ramificar y fusionar en 3 direcciones (pero con una interfaz web GUI).

En mi humilde opinión, el historial de revisión de documentos de Google no sería adecuado para importar a un proyecto git de todos modos. El problema es que no existe la noción de una copia de trabajo. A medida que las personas realizan cambios, se reflejan inmediatamente en el documento y se añaden al historial de revisiones. Ver la historia resulta ser un desastre profano.

El Revisionator (como bzr, mercurial, git, etc.) tiene la noción de una copia de trabajo. Por lo tanto, puede trabajar en un cambio hasta que esté listo para ser lanzado. Cuando se publica, aparece como una revisión en el historial de revisiones (mucho más legible).

— jpalmucci
fuente

Estoy de acuerdo en que es un desafío lidiar con una gran cantidad de revisiones como esa, pero al menos parece posible agruparlas en paquetes cuando hay una pausa en la edición o un cambio en quién está haciendo los cambios.

— nealmcb

Tal vez, pero no si diferentes personas están editando el documento al mismo tiempo. E incluso si los agrupa por tiempo, no hay garantía de que los grupos representen un solo cambio lógico en el documento. Es decir, trabajo en una revisión, me alejan. Vuelve más tarde y arréglalo. La gente ve 2 grupos de cambios en el historial de revisiones (y el documento roto en el medio).

— jpalmucci