Uso de Git para escribir la tesis

Question

Estoy planeando usar Git para escribir mi tesis con látex. Como Git está diseñado específicamente para el desarrollo de software, ¿sería factible para mis requisitos? Si es una buena opción para mí, entonces ¿qué características especiales y únicas están disponibles en Git que son ideales para escribir una tesis? También quiero saber qué precauciones debo tomar antes de entrar en el flujo de trabajo de Git. Soy un principiante completo para Git, entonces, ¿cuál debería ser mi punto de partida antes de entrar en él?

Answer 1

Existen algunas consideraciones técnicas y mejores prácticas. Voy por el segundo, específicamente para escribir su tesis y/o documentos. Para los técnicos, puedes consultar cualquier tutorial de git.

1. Defina la estructura del directorio para su tesis. Puede cambiarlo más tarde, y usar git para rastrear los cambios. Tener una buena estructura te haría la vida más fácil.

2. Trabaja con múltiples archivos (use include y/o input en LaTeX). Puede dividirlos por capítulos o secciones. Esto facilitará el seguimiento de los cambios que involucran partes específicas de su tesis (por ejemplo, git log content/introduction.tex).

3. Haga un seguimiento de los archivos que va a tocar, no los que se generan automáticamente. Crear un archivo proper .gitignore le ayudará mucho (LaTeX genera muchos archivos de trabajo).

4. Al igual que en los programas, realice microcompromisos, es decir: un compromiso por idea/función/arreglo/actividad.

5. Cada vez que se comprometa, escriba mensajes significativos (alto nivel) que expliquen lo que estaba tratando de lograr en cada cambio. Después de una semana, es posible que no recuerdes lo que intentaste lograr.

6. Hacer un seguimiento de cada actividad/idea/solución [ver (4) y (5)] podría ser muy útil para saber cuánto ha hecho (usando git log). Puede escribir su informe anticipado para su (s) supervisor (es) a partir del git log. Aún más, puede compartir el repositorio con su supervisor (usando una interfaz web), y puede verificar lo que ha estado haciendo en su tesis. Para la próxima reunión, sabrán qué esperar (dependerá de qué tan afectos estén sus supervisores al seguir un RSS).

7. El uso de git será útil para mantenerlo de buen humor (a veces sentiría que no ha hecho demasiado, pero tener un seguimiento de cada cambio le ayudará a mantener las cosas en perspectiva).

8. Por cada informe de progreso que envíe, cree una etiqueta. Para el próximo informe, puede consultar ambas versiones y aplicar latexdiff. Será útil para rastrear los cambios entre las versiones que envíe para su revisión. Esto también lo ayudará a verificar si respondió los comentarios que recibió en el informe anterior.

Por último pero no menos importante, recomiendo que lea "A successful Git branching model". Es un artículo muy breve sobre un flujo de trabajo de git. Puede aplicar los mismos conceptos cuando escribe su tesis. Por ejemplo, si está escribiendo un experimento, puede crear una rama para él y fusionarlo una vez que esté "listo". Si tiene que volver a visitarlo más tarde, sería más fácil ver cuáles fueron los cambios involucrados y por qué.

Answer 2

Git funcionará. El látex es efectivamente el código fuente, por lo que debería estar perfectamente bien.

Dicho esto, Git, aunque impresionante, tiene una curva de aprendizaje un poco empinada porque permite muchas cosas para colaborar con varias personas, manejar historias divergentes, etc. Su gran ventaja es la fusión de conflictos (¿qué sucede si cambio un archivo y alguien más cambia un archivo y ambos intentamos cargarlo/enviarlo a algún servidor?).

Si solo desea versionar su tesis, es poco probable que llegue al caso de fusión conflictiva (ya que es el único que lo está editando), y mucho menos al caso de múltiples historias.
Usaría algo más simple como SVN, que si bien es peor para hacer las dos cosas que describí, se ajusta a sus necesidades y es más fácil de aprender.

Además, git almacena todo en un archivo .git en la carpeta en la que se encuentra. Si elimina esa carpeta, sus datos desaparecerán.

Answer 3

En un DVCS, un "workflow" significa:

• flujo de trabajo de combinación (que no debería ser necesario que tanto en su caso)
• flujo de trabajo de publicación (pulsar para un acuerdo de recompra a distancia)

con tu repositorio git local, usted será capaz de comparar con las versiones anteriores (que puede venir muy bien)
Pero el beneficio de un DVCS es cuando:

• guardar su trabajo a través de un empujón a un acuerdo de recompra a distancia (o, por backup purposes, a bundle)
• que sincronice el trabajo, entre dos equipos diferentes (como en "How to push a local git repository to another computer?" o en "git server between laptop and PC (MS Windows 7)").
  Luego, una vez que se realiza la sincronización (a través de git push), puede sacar su segundo entorno completamente fuera de línea y aún beneficiarse del historial completo de su repositorio.
  Ahí es donde un DVCS importa en su caso.

Answer 4

Cuando estaba escribiendo mi tesis de doctorado, ¹ utilicé git para gestionar el documento y todas sus figuras, y estoy muy contento de haberlo hecho, sobre todo porque hace que sea más fácil escribir un guión que graphs your progresss como vas a lo largo;) Las principales ventajas que encontré fueron:

• Desde Git es un sistema de control de versiones distribuido, es fácil de trabajar en múltiples máquinas. Si necesita la última versión de su computadora portátil en su máquina de escritorio, puede simplemente pull directamente desde la computadora portátil y trabajar allí. Cuando te vas, vas a tu computadora portátil y la sacas de la máquina de escritorio.
• Si trabaja en varias máquinas, efectivamente tiene una copia de seguridad reciente de su trabajo (incluido su historial completo), y si desea crear más copias de seguridad puede simplemente ingresar a un nuevo repositorio vacío en otro lugar (como señala VonC's answer) .
• Puede hacer grandes cambios en su documento sabiendo que la versión anterior está almacenada de forma segura, y que si desea recuperar la versión anterior, eso es fácil de hacer.
• Ser capaz de comprometerse con su repositorio cuando no está conectado es muy útil, especialmente porque no tener acceso a Internet hace que sea mucho más fácil escribir;) También guardé los PDF de todos los documentos que cité en el mismo repositorio para es más fácil trabajar fuera de línea, aunque esto infló enormemente el repositorio, por lo que algunos podrían aconsejar contra eso.

El principal consejo que le daría:

• Commit frecuencia, y siempre asegúrese de que usted mantenga la salida de git status vacío, ya sea mediante la adición de archivos que necesita, o enumerarlos en .gitignore. No quiere arriesgarse a que no se rastreen los archivos importantes.
• Nunca utilice los comandos de reescritura del historial (por ejemplo, git rebase), solo para estar seguro y nunca use los comandos peligrosos de git como git reset --hard y git checkout -f. Nadie verá tu repositorio completo, por lo que no te importa cómo se ve la historia; es mucho más importante que no hagas nada que pueda perder (o dificultar la recuperación) tu trabajo.
• Cuando busque diferencias entre sus versiones, use la opción --color-words en git diff. De lo contrario, tus difs estarán basados ​​en líneas, y si vuelves a formatear un párrafo en LaTeX, será difícil ver cuáles son los cambios reales: git diff --color-words ignora los saltos de línea y solo muestra las palabras viejas en rojo y el nuevo palabras en verde.

¹ ... con LyX lugar de hacerlo directamente en LaTeX, pero los problemas son esencialmente los mismos.

Answer 5

Esto se entiende principalmente como un comentario, pero resultó ser demasiado largo, por lo que lo estoy publicando como respuesta.

Utilicé darcs para mi tesis de maestría, y he estado utilizando RCS, CVS y SVN para muchos proyectos de documentación/escritura en el pasado. Todas estas herramientas brindan la característica básica que quiero: capacidad de revisar mis cambios, retroceder en la historia, verificar los "puntos de deshacer" cuando empiezo a escribir algo nuevo.

Existen recomendaciones antiguas y comprobadas para escribir documentación con control de versión. Usar un formato de solo texto es importante para obtener diferencias sanas. Además, un consejo útil que recogí (IIRC de Kernighan, escribiendo sobre mantener la fuente de Troff en control de versiones) es asegurarme de que todas las líneas sean razonablemente cortas. Tiendo a golpear, ingreso cada pocas líneas, con miras a mantener una cláusula particular o modismo en una línea, de modo que la diferencia será mínima si decido revisar ese detalle en particular más adelante.