flujo de trabajo de git + LaTeX

Estoy escribiendo un documento muy largo en LaTeX. Tengo mi computadora de trabajo y mi computadora portátil, y trabajo en ambas. Necesito mantener todos los archivos sincronizados entre las dos computadoras, y también me gustaría mantener un historial de revisiones. Elegí git como mi DVCS, y estoy alojando mi repositorio en mi servidor. También estoy usando Kile + Okular para hacer la edición. Kile no tiene un complemento git integrado. Tampoco estoy colaborando con nadie en este texto. También estoy pensando en poner otro repositorio privado en el conjunto de datos, si mi servidor por alguna razón no es accesible.

¿Cuál es la práctica de flujo de trabajo recomendada en este caso? ¿Cómo se puede adaptar la ramificación en este esquema de trabajo? ¿Hay alguna manera de comparar dos versiones del mismo archivo? ¿Qué pasa con el uso de un alijo?

Cambios en su flujo de trabajo de LaTeX:

El primer paso para administrar eficientemente un flujo de trabajo de Git + LaTeX es hacer algunos cambios en sus hábitos de LaTeX.

• Para empezar, escribe cada oración en una línea separada . Git se escribió en el código fuente del control de versiones, donde cada línea es distinta y tiene un propósito específico. Cuando escribe documentos en LaTeX, a menudo piensa en términos de párrafos y lo escribe como un documento que fluye libremente. Sin embargo, en git, los cambios en una sola palabra en un párrafo se registran como un cambio en todo el párrafo.

  Una solución es usar git diff --color-words(vea mi respuesta a una pregunta similar ¿ Cómo usar Mercurial para el control de versiones de documentos de texto? Donde muestro un ejemplo). Sin embargo, debo enfatizar que dividir en líneas separadas es una opción mucho mejor (solo lo mencioné al pasar esa respuesta), ya que he encontrado que resulta en conflictos de fusión muy mínimos.

• Si necesita mirar el código diff, use el diff nativo de Git. Para ver la diferencia entre dos confirmaciones arbitrarias (versiones), puede hacerlo con la shas de cada una de las confirmaciones. Consulte la documentación para obtener más detalles y también Mostrar qué archivos han cambiado entre dos revisiones .

  Por otro lado, si necesita mirar la diferencia de su salida formateada , use la latexdiffcual es una excelente utilidad (escrita en perl) que toma dos archivos de látex y produce una salida clara y ordenada en pdf como esta ( fuente de la imagen ):

  

  Puede combinar gity latexdiff(más latexpandsi es necesario) en un solo comando usando git-latexdiff (por ejemplo, git latexdiff HEAD^para ver la diferencia entre su árbol de trabajo y el último compromiso pero uno).

• Si está escribiendo un documento largo en LaTeX, le sugiero dividir los diferentes capítulos en sus propios archivos y llamarlos en el archivo principal con el \include{file}comando. De esta forma, le resulta más fácil editar una parte localizada de su trabajo, y también es más fácil para el control de versiones, ya que sabe qué cambios se han realizado en cada capítulo, en lugar de tener que resolverlo a partir de los registros de un gran expediente.

Usando Git eficientemente:

• ¡Usa ramas! . Quizás no haya un mejor consejo que pueda dar. He encontrado que las ramas son muy útiles para realizar un seguimiento de "ideas diferentes" para el texto o para "estados diferentes" del trabajo. losmaster rama debe ser su cuerpo principal de trabajo, en su estado más reciente "listo para publicar", es decir, si de todas las ramas, si hay una que está dispuesto a poner su nombre, debe ser la rama maestra.

  Las sucursales también son extremadamente útiles si eres un estudiante graduado. Como atestiguará cualquier estudiante de posgrado, el asesor está obligado a tener numerosas correcciones, la mayoría de las cuales no está de acuerdo. Sin embargo, se espera que al menos los cambie por el momento, incluso si se revierten más tarde después de las discusiones. Entonces, en tales casos, puede crear una nueva rama advisory hacer cambios a su gusto, al mismo tiempo que mantiene su propia rama de desarrollo. Luego puede fusionar los dos y elegir lo que necesita.

• También sugeriría dividir cada sección en una rama diferente y enfocar solo la sección correspondiente a la rama en la que se encuentra. Genera una rama cuando crea una nueva sección o secciones ficticias cuando realiza su confirmación inicial (su elección, en realidad). Resista el impulso de editar una sección diferente (por ejemplo, 3) cuando no está en su rama. Si necesita editar, confirme este y luego revise el otro antes de bifurcar. Encuentro esto muy útil porque mantiene el historial de la sección en su propia rama y también le dice a simple vista (desde el árbol) la antigüedad de alguna sección. Tal vez haya agregado material a la sección 3 que requiere ajustes a la sección 5 ... Por supuesto, estos, con toda probabilidad, se observarán durante una lectura cuidadosa, pero me parece útil ver esto de un vistazo para poder cambiar de marcha si yo'

  Aquí hay un ejemplo de mis ramas y fusiones de un artículo reciente (uso SourceTree en OS X y Git desde la línea de comandos en Linux). Probablemente te darás cuenta de que no soy el responsable más frecuente del mundo ni dejo comentarios útiles todo el tiempo, pero esa no es razón para que no sigas esos buenos hábitos. El mensaje principal es que trabajar en sucursales es útil. Mis pensamientos, ideas y desarrollo proceden de manera no lineal, pero puedo seguirlos a través de ramas y fusionarlos cuando estoy satisfecho (también tuve otras ramas que no llevaron a ninguna parte que luego se eliminaron). También puedo "etiquetar" los commits si significan algo (por ejemplo, envíos iniciales a revistas / envíos revisados ​​/ etc.). Aquí, lo he etiquetado como "versión 1", que es donde está el borrador a partir de ahora. El árbol representa una semana '

  

• Otra cosa útil que puede hacer es realizar cambios amplios en el documento (como cambiar \alphaa \betatodas partes) por su cuenta. De esa forma, puede revertir los cambios sin tener que deshacer otra cosa junto con él (hay formas de hacerlo usando git, pero bueno, si puede evitarlo, ¿por qué no?). Lo mismo ocurre con las adiciones al preámbulo.

• Use un repositorio remoto y empuje sus cambios corriente arriba regularmente. Con proveedores de servicios gratuitos como GitHub y Bitbucket (ambos le permiten crear repositorios privados con una cuenta gratuita), no hay razón para no usarlos si está trabajando con Git / Mercurial. Como mínimo, considérelo como una copia de seguridad secundaria (¡espero que tenga una primaria!) Para sus archivos LaTeX y un servicio que le permite continuar editando desde donde lo dejó en una máquina diferente.

Tengo un flujo de trabajo similar también. Aunque se está trabajando en una rama a la vez, me parece beneficioso tener ramas separadas para diferentes estados de trabajo. Por ejemplo, imagine enviar un buen borrador de su trabajo a su asesor. ¡Entonces, tienes una idea loca! Desea comenzar a cambiar algunos conceptos básicos, volver a trabajar algunas secciones principales, etc. etc. Así que se ramifica y comienza a trabajar. Su rama maestra siempre está en un estado "liberable" (o tan cerca como usted en ese momento). Entonces, mientras su otra sucursal está loca y tiene algunos cambios drásticos, si otro editor quiere ver lo que tiene, o si es un estudiante que se presenta a una conferencia, la sucursal maestra siempre es liberable, lista para funcionar (o lista para mostrar su tutor). Si su asesor de doctorado quiere ver el borrador a primera hora de la mañana,

Digamos que su rama maestra tiene el estado "liberable" de su trabajo. Ahora desea enviarlo a varias revistas revisadas por pares, cada una con diferentes requisitos de formato para el mismo contenido y espera que vuelvan con varias pequeñas críticas diferentes sobre cómo puede editar el documento para adaptarse a sus lectores, etc. Puede crear fácilmente una rama para cada revista, realizar cambios específicos de la revista, enviar y, cuando reciba los comentarios, realizar los cambios en cada rama por separado.

También he usado Dropbox y git para crear el sistema que describiste anteriormente. Puede crear un repositorio básico en su carpeta de Dropbox. Luego puede empujar / tirar desde cualquier computadora a su Dropbox para mantenerse actualizado en todos los extremos. Este sistema generalmente solo funciona cuando el número de colaboradores es pequeño, ya que existe la posibilidad de corrupción si las personas intentan ingresar al repositorio de Dropbox al mismo tiempo.

Técnicamente, también podría mantener UN repositorio dentro de la carpeta de Dropbox y hacer todo su trabajo desde allí. Sin embargo, desalentaría esto, ya que la gente ha mencionado que Dropbox tiene algunos problemas para sincronizar archivos que cambian constantemente (archivos internos de gits).

Traté de implementar esto como una función bash, lo he incluido en mi ~/.bashrcpara que siempre esté disponible.

function git-latexdiff {    
    if [[ $# != 2 ]];    
    then      
        printf "\tusage: git-latexdiff <file> <back-revision>  \n";    
    elif [[ $2 -lt 0 ]];     
    then     
        printf "\t<Back-revision> must be positive\n";   
    else      
        dire=$(dirname $PWD/$1);      
        based=$(git rev-parse --show-toplevel);      
        git show HEAD~$2:$(echo $dire| sed 's!'$(echo $based)'/!!')/$1 > $1_diff.tmp;      
        latexdiff $1 $1_diff.tmp > $1_diff.tex;      
        pdflatex $1_diff.tex;     
        okular $1_diff.pdf;      
        rm $1_diff*;   
    fi; 
}

Tenga en cuenta que esta función debe latexdiffinstalarse (y encontrarse en la ruta). También es importante que encuentre pdflatexy okular.

La primera es mi forma preferida de procesar LaTeX, para que también puedas cambiarlo latex. El segundo es mi lector de PDF, supongo que querrás usarlo evincebajo gnome, o alguna otra solución.

Esta es una versión rápida, hecha con un solo documento en mente, y eso es porque con git, perderá mucho tiempo y esfuerzo rastreando un documento LaTeX de múltiples archivos. También puede dejar que git haga esta tarea, pero si lo desea, también puede continuar usando\include

Otra opción es usar Authorea, que es una especie de Github para artículos científicos. Cada artículo en Authorea es un repositorio de Git. Y el LaTeX que compones se procesa en HTML5 (así como en PDF, cuando compilas).

use esto para la versión diff en caso de que esté en Windows, sin instalación, solo un batscript simple Funciona perfectamente en windows10, miktex2.9:

https://github.com/redreamality/git-latexdiff