Si has tenido que entregar un trabajo escrito, o un proyecto para la universidad, muy probablemente has tenido esto en tu escritorio:
Es muy importante darse cuenta de que un documento que escribes, ya sea código fuente, documentación, un libro, una tesis, no es solamente el producto que entregas al final. Es también el proceso de pensamiento por el que pasas para poder llegar a ese producto.
Ese proceso muy rara vez es lineal. Muy pocos libros se escriben comenzando desde la introducción, y escribiendo cada capítulo en orden. Muy pocos proyectos de software comienzan con la pantalla de inicio.
El proceso de pensamiento en muchas ocasiones es caótico y desordenado. Pero sobre todas las cosas, los pensamientos son orgánicos, tenemos decenas de pensamientos cada día, pero solo algunos de estos se quedan en la mente. Algunos de estos pensamientos son difíciles de concebir, de hacer crecer, mientras que otros parecieran que crecen más rápido que nuestra misma capacidad de concebirlos.
Cada idea que tenemos es el resultado de ensayar varias posibilidades. No podemos escogerlas todas, hay que tomar decisiones en el camino. Algunas veces es muy conveniente poder ir atrás en el tiempo, y explorar otra posibilidad, lo que lleva la idea por otro camino.
Un control de versiones es un software que facilita este proceso. Es capaz de tomar fotos de un documento y compararlos en el tiempo. En cada comparación podemos ver qué cosas se agregaron, se quitaron o se cambiaron. Es capaz de tomar una de esas fotos y formar una línea de tiempo. Todo lo escrito va para un repositorio, el cual preserva toda esta información.
Pero de todas las funcionalidades, la más importante es tener la capacidad de comunicar y compartir cambios en el documento/código a otras personas que están trabajando sobre el mismo proyecto. En casi todos los sistemas el proceso es similar: cada integrante descarga una copia del proyecto a un «directorio de trabajo», allí hace los cambios, y luego manda los cambios de vuelta al repositorio. El sistema incorpora los cambios hechos por otros participantes de la manera más transparente posible, pero si no es posible integrar los cambios (por ejemplo, dos personas cambiaron la misma línea de texto), entonces el sistema deja al usuario el trabajo de seleccionar cuáles cambios continúan o se revierten.
No es mi objetivo enseñar específicamente cómo utilizar un control de versiones. Creo que hay recursos en línea que son mucho mejores y están disponibles inmediatamente, y a los que haré referencia al final del artículo.
Si escribo esto, es para animar a aquellos interesados en programar a que aprendan también a manejar un control de versiones. Esto es algo que muchas veces se aprende en una oficina y no en una universidad (donde supuestamente se aprende esta clase de cosas).
Por otro lado, muchos escritores no tienen el conocimiento tecnológico para incorporar un control de versiones en su trabajo (¿instalar un servidor?, ¿cómo guardo mis cosas?). Sin embargo, ver un recurso como GitBook me hace pensar que es posible traer a los escritores las ventajas del control de versiones sin pagar tanta penalidad en el aprendizaje de su manejo. Si eres escritor regular me gustaría saber tus opiniones al respecto.
Si necesitas saber más sobre el control de versiones, el libro Version Control By Example, de Eric Sink, es una de los mejores libros que he leído sobre el tema, e incluye los sistemas más populares. Si tu intención es, además, ser desarrollador profesional de videojuegos, en algún momento te encontrarás con Perforce, el cual es un servidor centralizado, similar a Subversion. Cuenta además con una versión gratuita para un límite de usuarios, lo que te permite probarlo sin costo alguno.