Los sistemas de control de versiones o sistemas de control de código fuente son programas que mantienen el histórico de todos los cambios realizados sobre archivos y carpetas a lo largo del tiempo. Esto permite volver a cualquier punto del pasado en cualquier momento, y también comparar un punto del tiempo con otro para conocer los cambios exactos que se han producido entre ambos. Además almacenan también quién es el autor de cada cambio y facilitan mucho el trabajo en paralelo de varias personas en varias características.
Existen multitud de sistemas de control de código: locales, centralizados o distribuidos. Más apropiados para código fuente o para archivos grandes como gráficos o vídeos. Instalados en un servidor local o utilizados desde Internet...
La lista de software para control de código es extensísima, pero los más conocidos son Mercurial, Subversion, PlasticSCM (que además de ser un proyecto alucinante, está creado desde cero en Valladolid para el mundo), y por supuesto el rey de todos ellos: Git, creado por Linus Torvalds hace ya más de una década y que se ha convertido en el estándar de facto de la industria.
Hoy en día es inevitable usar el control de código fuente en cualquier proyecto. Debería estar castigado con las penas del infierno de los programadores el hecho de no utilizarlo.
Es por esto que he intentado recopilar lo que considero que deberían ser los 10 mandamientos del control de código fuente, tal cual debería haberlos bajado el propio Linus Torvalds desde las montañas para entregarlas a sus seguidores. Las 10 reglas básicas de comportamiento que todo programador debería seguir a la hora de trabajar con este tipo de sistemas.
Ahí van:
1.- Utilizarás control de código sobre todas las cosas para todos tus proyectos
Da igual que sea un proyecto personal en el que solo trabajes tú. Deberías usar control de código fuente, aunque sea con un repositorio local sin respaldo en un servidor. De este modo podrás ir guardando todos los estados importantes del proyecto y volver a cualquier punto anterior, ver qué decisiones y cambios te llevaron al punto actual, etc...
Por supuesto en un equipo, aunque sea de dos, es indispensable. Con servicios gratuitos de repos privados como Bitbucket, Gitlab o el propio Visual Studio Team Services de Microsoft (que también soporta Git) no hay disculpa para no hacerlo.
2.- No te irás nunca a casa sin hacer un commit y un push
Es decir, sin dejar el código perfectamente salvaguardado y recuperable desde cualquier sitio, esté en el estado que esté (más sobre esto luego).
No en vano en algunos sitios el procedimiento anti-incendios incluye un cartel como este:
:-)
Aunque este sea para Git, vale para cualquier otro VCS: confirma y almacena antes de irte, aunque sea a comer.
3.- Inspeccionarás tus cambios con cuidado antes de hacer un commit
Lo de crear un commit es tan sencillo que lo hacemos de manera rutinaria, sin fijarnos. Mal hecho. Debemos prestar atención a que todos los archivos necesarios están en el área de preparación. A veces los archivos nuevos no se han añadido. O puede que se hayan agregado archivos que son temporales y no deberían estar ahí. ¿Y qué pasa con archivos que has editado pero que realmente no han cambiado finalmente tras varios cambios? No deberías subirlos y meter más ruido en el commit.
Para ello, revisa siempre bien los cambios antes de subirlos y asegúrate de que solo va lo que es realmente necesario. Utiliza incluso la herramienta de comparación si tienes dudas.
4.- Harás commit con frecuencia
Muchas personas tienen miedo de hacer commits con cosas a medio terminar y que luego se vean así en el histórico, como si todas las características de un desarrollo de software llegaran a la perfección al mismo tiempo que las escribimos. En absoluto. No pasa nada por tener cosas a medias o feas o con "ñapas" mientras no hemos terminado el desarrollo. Es preferible a tener un solo commit varios días después. Perdemos trazabilidad, ideas, conocimiento de cómo el código llegó a ser como es, y es imposible que otras personas del equipo conozcan el progreso actual del trabajo.
Deberías hacer un commit cada vez que tengas código que deseas guardar, porque tiene algo interesante, está una parte completa o, simplemente, te marchas y quieres dejar el trabajo salvaguardado. No pasa absolutamente nada. Además, si quieres dejarlo bonito más tarde también puedes hacerlo mediante cherry picking u otras técnicas. Pero, ¿para qué?.
Además recuerda que en sistemas distribuidos como Git, el hecho de hacer un commit no implica que debas hacer un push y subirlo al repositorio remoto. Los repos locales son para llevar control de tu trabajo y protegerlo. Los repos remotos son para pasar el trabajo a tus compañeros, controlar el trabajo de todos y, también, tener copias de seguridad.
Deberías enviar el código al remoto al menos una vez al día, pero no necesariamente cada vez que hagas un commit. Por lo demás, no te cortes y haz tantos commits como necesites.
5.- Te asegurarás de que los comentarios valen para algo
No hay nada peor que mensajes en un commit que no dicen nada de valor, como el mensaje de este cartel (clásico en marketing):
¿Qué aporta ese mensaje ahí? Absolutamente nada. Ya sabemos que Pizza Hut tiene pizza...
Pues lo mismo ocurre con los mensajes que se ven en los repositorios muchas veces (por no mencionar en los comentarios de código).
Solo hay algo peor que un mensaje redundante: mensajes tan largos que acaban por no servir tampoco de nada, porque encima dan trabajo extra al leerlos.
Un mensaje de commit debería ser conciso pero al mismo tiempo informativo, aportando valor. Debería tener todo lo necesario pero no más. Por lo tanto debería enumerar los cambios importantes que se han hecho y por qué. Esto ayuda a localizar el punto en el que se cambió un comportamiento, una característica o se corrigió un bug. También ayuda a ver de un golpe rápido de vista el trabajo que se ha realizado recientemente y su progreso.
Si vas a hacer muchas cosas una mañana, no pasa nada: haz varios commits y procura que en cada uno haya un mensaje útil sobre cada cosa.
6.- Harás un Fetch/Pull antes de hacer un commit
Antes de empezar a trabajar en tu código después del último commit, haz un fetch o un pull para traerte los cambios del remoto y traer lo último que hayan hecho tus compañeros. Evitarás muchos conflictos en el futuro, y sobre todo evitarás sobrescribir su trabajo si no los gestionas bien.
Esto es de extrema importancia en sistemas no distribuidos como Subversion, porque directamente podrías cargarte el trabajo de los demás. Otros sistemas como Git no permiten que ocurra tan fácilmente (aunque sigue siendo buena costumbre hacerlo para evitar problemas).
Recuerda: antes de nada, tráete los cambios que haya.
7.- No harás push directamente al master
Esto ya no deberían permitirlo los administradores del repositorio, pero cada característica o bug debería trabajarse en su propia rama, y es ahí en dónde se deberían recibir todos los push. Estas ramas deberían salir a su vez de la rama de desarrollo, así que una vez terminado el trabajo en cuestión, la rama debería mezclarse con la de desarrollo.
Solo el código definitivo, bien probado y revisado debería ir al master, y para ello debería ser necesario un Pull Request que alguien deba aprobar. Algunos sistemas de repositorios como Bitbucket o GitLab, por defecto ya lo tienen configurado así para evitar problemas.
Si utilizáis alguna metodología de gestión de ramas como Git-Flow (que deberíais), entonces ya será así como trabajarás.
8.- Comprenderás bien la herramienta de mezcla y comparación
Los conflictos son inevitables al mezclar ramas y al recibir actualizaciones desde los remotos. Así que aprende bien a manejar las herramientas de comparación que integres en tu sistema de trabajo. Pueden ser las herramientas de "diff" de tu cliente de Git favorito o alguna herramienta externa potente (y gratuita) como WinMerge, que a mí personalmente me encanta.
Cuando surja un conflicto será tu salvación. Y cuando no haya conflictos pero necesites ver qué ha cambiado en varias versiones de los archivos para descubrir un bug, también.
9.- Versionarás tus bases de datos y otras cosas
Hay quien se piensa que el control de código fuente solo sirve para código, porque lo lleva en el nombre. En absoluto. Deberías gestionar en él todo lo que tenga que ver con el proyecto, como documentación interna y externa (sobre todo si está en Markdown), gráficos, especificaciones, diagramas de flujo... y sobre todo las versiones de tu base de datos.
Para ello no es necesario que guardes la base de datos, sino su esquema en formato instrucciones SQL para poder reconstruirla en cualquier momento y conocer su evolución en el tiempo.
Cada vez que se realice un cambio sobre la base de datos puedes generar su esquema a un archivo de texto y archivarlo con el resto del código fuente. Puedes hacerlo con alguna herramienta especializada que lo automatice o puedes hacerlo a mano. Pero hazlo.
Estos elementos son tan importantes como el código en sí y deben ser guardados y gestionados con el mismo mimo.
10.- Excluirás tus mierdas cosas del control de código
No hay nada más molesto que un compañero que sobrescribe tus ajustes personales en cada commit. Y es que hay muchas cosas que no deberían estar bajo control de código fuente: tus ajustes personales en el editor de código que utilices, los archivos auxiliares que solo utilizas tú, resultados de las compilaciones (las famosas carpetas "bin" y "obj" por ejemplo), dependencias (carpetas "node_modules", "packages" y similares), etc...
Para algo se inventó el archivo .gitignore en Git o la propiedad svn:ignore en Subversion, por citar los más conocidos. Mete ahí los archivos y carpetas (o plantillas de archivos y carpetas) a excluir del control de código, y asegúrate que no incluyes cosas molestas o contingentes.
En resumen
Todos estos mandamientos se resumen en uno solo: amarás al código sobre todas las cosas :-D
En serio. Seguramente muchas de las anteriores te parecen evidentes si has sabido usar este tipo de sistemas de la forma adecuada. Pero en mi experiencia, muchas personas se olvidan de lo básico y fastidian al resto del equipo y al código a largo plazo. También seguro que hay algunos consejos adicionales que se podrían añadir.
¿Cuál es tu experiencia? ¿Algún consejo más o puntualización? Déjalos en los comentarios de más abajo...
Fecha de publicación: