ver repositorio remota rama que modificados example ejemplo cambiar archivos git latex git-workflow

repositorio - git ver archivos modificados



git+flujo de trabajo LaTeX (5)

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 plugin git integrado. Tampoco estoy colaborando con nadie en este texto. También estoy pensando en poner otro repositorio privado en codaset, si mi servidor por algún motivo no es accesible.

¿Cuál es la práctica de flujo de trabajo recomendada en este caso? ¿Cómo encajar la ramificación en este esquema de trabajo? ¿Hay alguna manera de comparar dos versiones del mismo archivo? ¿Qué hay de usar 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 fue escrito en el código fuente de control de versión, 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 los escribe como un documento de flujo libre. 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 donde muestro un ejemplo). Sin embargo, debo enfatizar que dividir en líneas separadas es una opción mucho mejor (solo lo mencioné de pasada en esa respuesta), ya que he encontrado que resulta en conflictos de fusión muy mínimos.

  • Si necesitas mirar el código diff, usa el diff nativo de git. Para ver la diferencia entre dos confirmaciones arbitrarias (versiones), puede hacerlo con los sha s de cada una de las confirmaciones. Vea la documentation para más detalles y también esta pregunta.

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

    Puede combinar git y latexdiff (más latexpand si es necesario) en un solo comando usando git-latexdiff (por ejemplo, git latexdiff HEAD^ para ver la diferencia entre su worktree y la confirmación de último-uno-uno).

  • Si está escribiendo un documento largo en látex, sugeriría dividir diferentes capítulos en sus propios archivos y llamarlos al archivo principal usando el comando /include{file} . De esta manera, es más fácil para usted 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 una gran expediente.

Usando git eficientemente:

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

    Las sucursales también son de gran ayuda si eres un estudiante graduado. Como lo atestiguará cualquier estudiante graduado, el asesor está obligado a realizar numerosas correcciones, la mayoría de las cuales no están de acuerdo. Sin embargo, puede esperarse que al menos los cambie por el momento, incluso si se revierten más tarde después de las discusiones. Entonces, en tales casos, podría crear un nuevo advisor sucursal y hacer cambios a su gusto, al mismo tiempo que mantiene su propia rama de desarrollo. Luego puedes combinar los dos y elegir lo que necesites.

  • 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. Crea una rama cuando crees una nueva sección o secciones ficticias cuando realices tu compromiso inicial (tu elección, en realidad). Resista la tentación de editar una sección diferente (por ejemplo, 3) cuando no esté en su rama. Si necesita editar, confirme este y luego verifique 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 de un vistazo (desde el árbol) qué tan antigua es una sección. Tal vez haya agregado material a la sección 3 que requiere ajustes a la sección 5 ... Por supuesto, estos se observarán, con toda probabilidad, durante una lectura cuidadosa, pero me parece útil ver esto de un vistazo para que pueda Cambiar de marcha si me estoy aburriendo de una sección.

    Aquí hay un ejemplo de mis sucursales y combinaciones de un documento reciente (uso SourceTree en OS X y git desde la línea de comandos en Linux). Probablemente se dará cuenta de que no soy la persona más frecuente en el mundo, ni dejo comentarios útiles todo el tiempo, pero esa no es razón para que no siga esos buenos hábitos. El mensaje principal es que trabajar en las sucursales es útil. Mis pensamientos, ideas y desarrollo proceden de forma no lineal, pero puedo seguirlos a través de las sucursales y fusionarlas cuando esté satisfecho (también tuve otras sucursales que no llevaron a ninguna parte y que luego se eliminaron). También puedo "etiquetar" las confirmaciones 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 el trabajo de una semana.

  • Otra cosa útil a hacer sería realizar cambios en todo el documento (como cambiar /alpha a /beta todas partes) los confirmaciones por cuenta propia. De esa manera, puede revertir los cambios sin tener que retroceder otra cosa junto con él (hay formas de hacerlo utilizando git, pero bueno, si puede evitarlo, ¿por qué no?). Lo mismo ocurre con las adiciones al preámbulo.

  • Use un repositorio remoto y envíe sus cambios en sentido ascendente regularmente. Con proveedores de servicios gratuitos como github y bitbucket (este último incluso te permite crear repositorios privados con una cuenta gratuita), no hay razón para no usarlos si estás trabajando con git / mercurial. Como mínimo, considérelo como una copia de seguridad secundaria (¡espero que tenga una principal!) Para sus archivos de látex y un servicio que le permita continuar editando desde donde lo dejó en una máquina diferente.

Intenté implementar esto como una función bash, lo he incluido en mi ~/.bashrc para que esté siempre 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 necesita latexdiff para instalarse (y se encuentra en la ruta). También es importante que encuentre pdflatex y okular .

La primera es mi forma preferida de procesar LaTeX, por lo que también puede cambiarlo al latex . El segundo es mi lector de PDF, supongo que querrá usar evince bajo gnome, o alguna otra solución.

Esta es una versión rápida, hecha con un solo documento en mente, y esto se debe a que 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 trabajos científicos. Cada artículo en Authorea es un repo de Git. Y el LaTeX que compones se procesa en HTML5 (así como en PDF, cuando compilas).

También tengo un flujo de trabajo similar. Aunque se está trabajando en una rama a la vez, me parece beneficioso tener sucursales separadas para diferentes estados de trabajo. Por ejemplo, imagine enviar un buen borrador de su documento a su asesor. Entonces, tienes una idea loca! Desea comenzar a cambiar algunos conceptos básicos, volver a trabajar algunas secciones importantes, etc. Así que se ramifica y comienza a trabajar. Su rama maestra siempre está en un estado "liberable" (o lo más cerca que esté en ese momento). Entonces, si 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 usar (o lista para mostrar su tutor). Si su asesor de doctorado quiere ver el borrador a primera hora de la mañana, sí, podría esconder / poner en escena / confirmar sus cambios actuales, usar etiquetas o buscar en el registro, pero ¿por qué no mantener sucursales separadas?

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 que se ajuste a sus lectores, etc. Puede crear fácilmente una sucursal para cada revista, realizar cambios específicos de la revista, enviar y, cuando reciba los comentarios, realice los cambios en cada sucursal 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 / jalar desde cualquiera de las computadoras 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 las personas han mencionado que Dropbox tiene algunos problemas para sincronizar los archivos que cambian constantemente (archivos internos de Gits).