Soy escritor, no programador. Recién ahora estoy aprendiendo por primera vez sobre el control de versiones y cómo funciona, y me pregunto cómo el control de versiones podría optimizar mi flujo de trabajo.
En una pregunta anterior , pregunté qué sistema de control de versiones usar y me decidí por Git.
Durante años, he usado mi propia versión improvisada del control de versiones. Mis carpetas están repletas de archivos como resume-2012-06-01.doc, resume-2012-06-15.doc, letter.txt, letter-old.txt, letter-v2.txt, story-notes.txt, story -notas-con-bocetos-de-personajes.txt story_draft1.txt, story_draft2.txt, story_draft2-shorter.txt, etc.
Ahora que estoy usando el control de versiones, supongo que no necesito crear manualmente todas estas versiones renombradas de un archivo. ¿Qué debo hacer en su lugar? Ahora que estoy usando el control de versiones, ¿cómo debo nombrar mis borradores y reescrituras? ¿Cómo debo realizar un seguimiento de los borradores y las revisiones?
¿Qué filosofía y prácticas debe usar un escritor para comentar cuando realiza una confirmación de Git de reescrituras y revisiones para realizar un seguimiento de todo y encontrar las cosas fácilmente más adelante?
Hay dos conceptos en git que pueden ayudar: ramas y etiquetas .
Etiquetas. Piense en una etiqueta como un nombre para una revisión específica. Cada vez que desee recordar una versión, cree una etiqueta para ella. Por ejemplo, cuando termine un borrador, puede etiquetarlo así:
git tag first_draft
Cuándo usar etiquetas. Las etiquetas son buenas para marcar cualquier versión que desee recordar más tarde. Los uso para marcar el final de cada borrador.
Sucursales. Piense en una rama como una serie de cambios. La rama predeterminada se llama master. Esa es una buena rama para usar en la investigación inicial y el primer borrador. A menos que cree una nueva rama, cada cambio que realice actualiza la masterrama.
Cuándo usar ramas. Cada vez que desee comenzar una nueva serie de ediciones, tiene una opción. Puede continuar en la rama actual o crear una nueva rama.
Algunos usos posibles para las ramas:
Borradores. Puede comenzar cada borrador creando una rama para él. (Tiendo a no hacer esto, pero puede satisfacer sus necesidades).
Experimentos. Suponga que desea experimentar con la reescritura de algunas escenas para cambiar de primera persona a tercera, o para cambiar el personaje POV. Puedes crear una rama y hacer tus experimentos allí. Más tarde, si te gusta el nuevo POV, puedes seguir escribiendo en tu rama experimental. Si no le gustan los cambios de POV después de todo, puede volver a la rama en la que estaba antes.
envíos Antes de enviar un envío, a menudo creo una nueva rama, agrego mi carta de presentación, hago cambios menores en el manuscrito específicos para ese destinatario (por ejemplo, peculiaridades de los formatos mss) y agrego un archivo de texto con notas sobre el envío. Cuando recibo una respuesta, puedo consultar la sucursal y actualizar mis notas.
Tiendo a usar ramas más para experimentos y envíos que para borradores. Cuando termine un borrador, lo etiquetaré y continuaré con el segundo borrador en la masterrama.
Creación de sucursales. Para crear una nueva rama, use el git branchcomando como este:
git branch charles_pov
Cuando crea una nueva rama, la nueva rama comienza con el mismo contenido que la rama en la que estaba. Si está en la masterrama y crea una charles_povrama, la charles_povrama comienza con el contenido actual de la masterrama.
Tenga en cuenta que la creación de una nueva rama no cambia a la nueva rama. Para cambiar a una sucursal, consulte a continuación.
Cambio de sucursales.
Puede cambiar de sucursal en cualquier momento al "revisar" una sucursal. Para cambiar a su nueva charles_povsucursal:
git checkout charles_pov
Cuando confirma cambios, git actualiza cualquier rama en la que se encuentre y deja las otras ramas sin cambios. Entonces, si cambia a la charles_povrama, sus cambios actualizarán la charles_povrama y la masterrama permanecerá sin cambios.
Crear una rama y cambiar a ella en un solo comando. Puede crear una nueva rama y cambiar a ella con un solo comando, así:
git checkout -b charles_pov
Visualización de etiquetas y ramas. Puede ver una lista de todas las etiquetas y ramas con estos comandos:
git tag
git branch
Revisando una etiqueta (Y UNA ADVERTENCIA). Recuerde que una etiqueta es un nombre para una versión específica. Si ha etiquetado cada borrador, puede ver un borrador antiguo como este:
git checkout twelfth_draft
Sí, revisas una etiqueta de la misma manera que revisas una sucursal.
PERO TENGA EN CUENTA que cuando revisa una etiqueta, ya no está en ninguna sucursal. Cualquier cambio que hagas termina en un lugar nebuloso flotante que no sé cómo explicar sucintamente. Git te advierte sobre esto.
La sucursal actual. Para ver en qué rama se encuentra actualmente, use este comando:
git branch
Git muestra todas las ramas y marca la rama actual (la que se actualizará cuando realice cambios) con un asterisco.
Solo para jugar un poco al abogado del diablo, creo que definitivamente se puede hacer un caso para no usar una herramienta de control de versiones de software por escrito.
Como escritor que también trabaja en la industria del desarrollo de software, tengo algunas teorías favoritas sobre esto, aunque todavía estoy experimentando.
En 1967, un programador de computadoras llamado Melvin Conway acuñó lo que se conoce como "Ley de Conway": "Las organizaciones que diseñan sistemas... están obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones".
Básicamente, esto significa que es muy probable (o incluso inevitable) que una pieza de software llegue a parecerse a la organización que la creó. Esto sucede porque el software (como la escritura) es "suave" y una parte de la funcionalidad se puede lograr de muchas maneras, por lo que un ingeniero de software está inherentemente más limitado por la organización para la que trabaja que por las herramientas que utiliza.
Tengo como corolario una teoría favorita de que las herramientas utilizadas para escribir influirán inevitablemente en la naturaleza del trabajo producido con ellas. Usted podría decir "¿y qué?" Después de todo, los sistemas de control de versiones diseñados para el desarrollo de software son herramientas maravillosas y poderosas que a veces permiten que cientos de ingenieros y desarrolladores colaboren de manera efectiva. Yo diría "exactamente".
La buena escritura tiene un objetivo final diferente al de la buena codificación. (No hablo de redacción técnica o documentación, sino de prosa). La escritura en prosa está destinada a crear una experiencia intensamente personal, uno a uno, entre el autor y el lector (que generalmente está tratando de relajarse y escapar de un mundo caótico y de rápido movimiento con un libro agradable pero que consume mucho tiempo). El producto del trabajo del escritor es directamenteexpuesto al lector (o usuario final) a diferencia de una pieza de software en la que el 99% del tiempo el código que escribe un desarrollador está oculto debajo de una capa de abstracción de una IU (interfaz de usuario) basada en lo visual. En casi cualquier aplicación de software, el disfrute de la aplicación por parte del usuario no tiene nada que ver con la calidad del código en la capa empresarial. Si el código está suficientemente bien escrito para que la aplicación sea funcional, la experiencia es la misma para el usuario si se trata de un código espagueti incomprensible o de un arte hermosamente minimalista y bien comentado. Este no es en absoluto el caso de un escritor.
Entonces, el objetivo de algo como Git es recopilar y preservar el código y permitir la trazabilidad y el control de cambios. Acumula cambios en el código de varios desarrolladores o de un solo desarrollador a lo largo del tiempo y le permite hacer cosas como entregar un conjunto de cambios, darse cuenta de que arruinó toda la aplicación y deshacer su cambio, o incluso integrar parte de él. El punto es preservar el estado funcional de la aplicación, no la "voz" cohesiva del código. El código no suele tener ninguna "voz" cohesiva, especialmente en los casos en los que un gran equipo ha colaborado en un proyecto. Entonces, si usa el control de versiones para escribir una novela, la herramienta lo alentará a mantener múltiples versiones de la novela simultáneamente, cambiar partes de una versión a otra, mantenga cada palabra que haya escrito en algún lugar y pueda volver a insertarlas, y cree un documento vivo en constante expansión sin un estado final. Una aplicación de software se reescribe continuamente hasta que se abandona. Cada vez que hay un ticket de defecto, una actualización de algo de lo que depende la aplicación, una actualización de un navegador que usa la aplicación o cualquier nueva entrega de funcionalidad, habrá cambios en el código en alguna parte. Las únicas aplicaciones de software estáticas e inmutables son el abandonware muerto. Una novela es totalmente diferente. Tienes que editar la novela y darle forma final e inmutable que no cambiará. Aunque es posible recibir una novela en constante cambio en un dispositivo como un Kindle, los lectores no quieren eso. Ellos don' No quiero tener que volver atrás en un libro que ya están leyendo y encontrar nuevos cambios en el capítulo 2 e intentar integrarlos en su comprensión de la historia. Los lectores quieren que un libro esté terminado y estático antes de empezar a leerlo.
Si su herramienta lo alienta a ser detallado, mantener versiones potencialmente infinitas de una historia y nunca necesitar llegar a un estado final, creo que muchos escritores, particularmente los menos experimentados que podrían tener una tendencia a ser demasiado detallado de todos modos, estarían más propensos a escribir novelas gigantescas de "bolas de barro" que finalmente son ilegibles. Lo digo como alguien cuya primera novela se ajusta a esa descripción.
Los escritores siempre han tenido alguna conexión con las herramientas que utilizan, razón por la cual la gente todavía asocia a los novelistas con máquinas de escribir que hacen clic. Las herramientas limitany obligarnos a tener en mente nuestro estado final antes de poner palabras en el papel. Hemingway escribió a mano en la era de las máquinas de escribir y muchos autores más modernos usaron máquinas de escribir en la era de las computadoras. No se trata de ser un ludita, se trata del impacto psicológico de saber que lo que pones en el papel es de alguna manera inmutable y no se puede deshacer fácilmente. Nos obliga a ser concisos, a elegir las palabras con cuidado y a escribir más en nuestro cerebro y menos en la herramienta. El control de versiones fomenta más escritura en la herramienta y menos en nuestro cerebro. Creo que ya hemos visto una avalancha de mala escritura en la era de los procesadores de texto, y el control de versiones podría ser un paso demasiado lejos en el camino equivocado cuando se trata de prosa.
Entonces, para responder a la pregunta: tal vez no. (?)
No sé si la funcionalidad sofisticada de git sería tan útil, a menos que tal vez esté colaborando con otro escritor. Sin embargo, git ofrece un par de cosas que son potencialmente interesantes o útiles para el escritor.
La primera, y algo trivial, es que hace las versiones contables de su texto por usted, sin preocuparse por qué nombres son cuáles, o preguntándose si está editando la versión correcta. Por lo tanto, puede permanecer en su rama maestra, realizar sus cambios diariamente, pero siempre tratar con archivos como Chapter01.md. Su versión sin el desorden.
Quizás lo más intrigante es que cuando se confirma, se le invita a agregar un comentario que describa la confirmación. Los programadores lo usan para indicar la naturaleza del cambio que se está realizando (p. ej., 'Corregir un error de indexación único'), pero más pertinente para el escritor podría ser una reflexión sobre lo que se escribió, una especie de diario del escritor que se lleva sobre la marcha. a lo largo de.
Mónica Celio