La v0.19 funciona y aguanta los errores, pero para llegar hasta ella has tocado almacen.py, modelo.py, interfaz.py y __main__.py a la vez. Si mañana descubres que la validación de dias rompe algo, ¿cómo vuelves atrás? ¿Y cómo sabes exactamente qué cambiaste el martes? La respuesta que usa todo el mundo desde hace veinte años es Git: un sistema que guarda la historia completa del proyecto, permite volver a cualquier punto anterior, deja probar ideas sin miedo y hace posible que varias personas trabajen sobre el mismo código sin pisarse. Esta lección te enseña Git desde cero: el modelo mental de las tres zonas, los comandos del día a día, cómo se escribe un buen mensaje de commit, qué no se versiona nunca, cómo se abren y se fusionan ramas —y cómo se resuelve un conflicto sin pánico—, cómo se deshace lo hecho y qué son GitHub y GitLab. Al final, TareaFácil vivirá en un repositorio con su historial.

1. El problema: proyecto_final_v3_bueno_definitivo
2. Instalar y configurar Git
3. El modelo mental: tres zonas
4. Los comandos del día a día
5. Qué es un commit y cómo se escribe su mensaje
6. .gitignore: lo que nunca se versiona
7. Ramas: trabajar sin miedo
8. Conflictos: qué son y cómo se resuelven
9. Deshacer: restore, revert y reset
10. Remotos: GitHub, GitLab y los pull requests
11. Etiquetas y versionado
12. TareaFácil v0.20: el proyecto bajo Git
13. Errores comunes y consejos
14. Ejercicios
15. Conclusión

Todo el mundo ha vivido esta escena: una carpeta con informe.docx, informe_v2.docx, informe_v2_revisado.docx, informe_final.docx e informe_final_BUENO.docx. Con código es peor, porque además hay que saber qué línea cambió entre dos versiones y por qué. Copiar carpetas falla en todo: ocupa espacio, no dice qué cambió, no explica el motivo, no permite mezclar el trabajo de dos personas y no hay forma de recuperar solo una parte.

Un sistema de control de versiones (VCS) resuelve exactamente eso: guarda instantáneas del proyecto con su fecha, su autor y una explicación, y permite comparar, volver atrás y combinar cambios. Hay dos familias. Los centralizados (Subversion, CVS) guardan la historia en un único servidor: sin conexión no se puede trabajar y si el servidor cae, se acabó. Los distribuidos (Git, Mercurial) dan a cada persona una copia completa del historial en su propio ordenador: se trabaja sin conexión, cada clon es una copia de seguridad y solo se sincroniza con el servidor cuando interesa. Git, creado en 2005 para el desarrollo de Linux, es hoy el estándar absoluto.

Git se descarga de git-scm.com (en Linux suele venir instalado o se instala con el gestor de paquetes). Para comprobarlo y configurarlo, tres órdenes que solo se ejecutan una vez por ordenador:

El nombre y el correo no son un trámite: quedan grabados para siempre en cada commit que hagas, y son lo que aparece cuando alguien pregunta quién tocó una línea. La opción --global los aplica a todos tus proyectos; sin ella, solo al repositorio actual, que es lo que se usa cuando el correo del trabajo y el personal deben separarse.

Esta es la parte que más cuesta al principio, y todo se aclara si entiendes que un cambio pasa por tres zonas antes de quedar guardado en la historia:

• Directorio de trabajo: tus ficheros tal y como están ahora en el disco.
• Zona de preparación (staging area o index): la lista de cambios que quieres incluir en el próximo commit. Es el gran acierto de Git: te deja elegir qué entra y qué no.
• Repositorio: la carpeta .git, donde viven todos los commits ya confirmados.

Gracias a la zona intermedia puedes haber tocado cinco ficheros y confirmar solo dos, dejando el resto para otro commit con su propia explicación. Esa disciplina —un commit, una idea— es lo que convierte el historial en algo útil de leer.

Con estos diez comandos se cubre el 95 % del trabajo:

Así se ve una sesión real en TareaFácil:

Fíjate en el detalle importante: se ha preparado un solo fichero aunque había dos modificados. El commit resultante cuenta una historia limpia, y el README.md esperará a su propio commit. git status es tu brújula: ejecútalo antes y después de cada operación hasta que el modelo mental te salga solo. Y antes de confirmar, git diff te enseña exactamente qué vas a guardar:

Las líneas con - son las que desaparecen y las que llevan +, las que entran; la cabecera @@ -38,7 +38,10 @@ indica en qué parte del fichero estamos. Leer un diff es la forma más rápida de revisar tu propio trabajo antes de confirmarlo.

Un commit es cuatro cosas a la vez: una instantánea del proyecto completo, un mensaje que explica el porqué, un autor con su fecha y un padre, el commit anterior. Esa cadena de padres es la historia, y cada commit se identifica con un hash, un código como 4f2a9c1 que sirve para referirse a él en cualquier comando.

El mensaje es la parte que más se descuida y la que más valor aporta dentro de seis meses. Las reglas aceptadas en todos los proyectos son tres: asunto corto (menos de 50 caracteres), en imperativo y sin punto final —«Añade», «Corrige», «Elimina», como si completaras la frase «este commit...»—, y si hace falta, una línea en blanco y un cuerpo que explique el porqué, nunca el qué (el qué ya lo dice el diff).

El segundo -m crea el cuerpo. Ese texto es exactamente lo que agradecerás cuando dentro de un año te preguntes por qué existe un fichero .json.bak en la carpeta.

No todo lo que hay en la carpeta debe entrar en el repositorio. Un fichero llamado .gitignore, en la raíz del proyecto, dice qué debe ignorar Git:

Las cuatro categorías son siempre las mismas: lo que se puede regenerar (__pycache__, el .venv, que se reconstruye con requirements.txt), los datos de cada usuario (el tareas.json de Marta no es el de Luis), la configuración personal del editor y, sobre todo, los secretos.

Esto último merece un aviso serio: no subas nunca contraseñas, claves de API ni datos personales a un repositorio. Y no basta con borrarlas después en un commit posterior, porque siguen estando en el historial y cualquiera puede recuperarlas; si el repositorio es público, hay robots que rastrean claves filtradas en cuestión de minutos. La regla es simple: las credenciales van en un fichero .env ignorado desde el principio, y si alguna se escapa, se revoca inmediatamente. Lo mismo vale para los datos personales de clientes reales.

Una rama es una línea de desarrollo paralela. Sirve para trabajar en algo —una funcionalidad nueva, un experimento, una corrección— sin tocar la versión que funciona, y para que dos personas avancen a la vez sin estorbarse. En Git son tan baratas que se usan constantemente.

git switch es la forma moderna; verás mucho git checkout en documentación antigua, que hace lo mismo (y más cosas, lo que lo hacía confuso).

En el diagrama, main siguió avanzando mientras la rama exportar-pdf hacía su trabajo, y el merge unió las dos historias en un commit de fusión. Mientras la rama existía, main estuvo siempre en un estado funcional: eso es lo que significa «trabajar sin miedo».

Un conflicto aparece cuando dos ramas han cambiado las mismas líneas del mismo fichero y Git no puede decidir cuál vale. No es un error ni una catástrofe: es Git pidiéndote que decidas tú. Al fusionar verás algo así:

Y dentro del fichero, las líneas en disputa aparecen marcadas:

La resolución tiene tres pasos, y ninguno es misterioso: abre el fichero y deja el contenido correcto, borrando las tres líneas de marcas (<<<<<<<, =======, >>>>>>>); prepara el fichero con git add tareafacil/interfaz.py; y cierra la fusión con git commit. Si te has liado, git merge --abort deja todo como estaba antes de intentarlo. El consejo práctico para tener pocos conflictos: ramas cortas, commits pequeños y fusionar a menudo.

Git permite deshacer casi cualquier cosa, pero no todas las formas son igual de seguras:

Fíjate en que el commit original sigue ahí: revert no lo borra, añade encima otro que aplica exactamente los cambios contrarios. La diferencia clave es esa: revert añade historia, reset la reescribe. Si el commit ya está compartido con otras personas, reescribir la historia les rompe el repositorio, así que la respuesta correcta es casi siempre git revert. Y git reset --hard merece un respeto especial: borra trabajo sin preguntar y no hay papelera. Úsalo solo en tu ordenador, sobre commits que nadie más ha visto, y después de comprobar con git status que no te dejas nada.

Un remoto es una copia del repositorio alojada en otro sitio, normalmente en un servicio como GitHub o GitLab. Sirve de copia de seguridad, de punto de encuentro del equipo y de escaparate: hoy un repositorio público es parte del currículum de cualquier programador.

Y una pieza más que verás en cuanto trabajes con otros: un pull request (o merge request en GitLab) es una petición formal de fusionar tu rama en la principal. Abre una página donde el equipo ve los cambios línea a línea, comenta y aprueba antes de integrar. Es el mecanismo con el que se revisa el código en prácticamente todos los proyectos, y funciona exactamente sobre las ramas que ya sabes crear.

Una etiqueta (tag) es un nombre permanente para un commit concreto, y su uso natural es marcar las versiones publicadas —justo los números que vienes viendo desde 08-01:

A diferencia de una rama, una etiqueta no se mueve: v0.20 señalará ese commit para siempre, así que dentro de un año podrás recuperar exactamente el código que se entregó. Aquí es donde el versionado semántico de 08-01 se hace tangible: v0.19, v0.20, v1.0 dejan de ser una convención mental para convertirse en puntos concretos y recuperables del historial.

Vamos a poner el paquete bajo control de versiones desde cero, con tres commits que cuentan una historia y una rama para una mejora:

El orden no es casual: el .gitignore va primero, antes de añadir nada más, para que el tareas.json con los datos reales no entre nunca en el historial. Ahora, la mejora en una rama:

Fast-forward significa que main no había avanzado mientras trabajabas, así que Git simplemente adelantó el puntero: ni siquiera hizo falta un commit de fusión. TareaFácil v0.20 tiene ya historial, autoría, mensajes que explican el porqué, una etiqueta y la capacidad de volver a cualquier punto anterior.

• Subir el entorno virtual o los datos. Crea el .gitignore antes del primer git add .; sacar algo del historial después es mucho más incómodo.
• Subir contraseñas o datos personales. Quedan en el historial aunque los borres luego. Usa un .env ignorado y revoca cualquier clave que se escape.
• Commits gigantes. «Cambios de la semana» con 40 ficheros no sirve para nada. Un commit, una idea.
• Mensajes vacíos (cambios, fix, asdf). Escribe en imperativo qué hace el commit y, si no es obvio, por qué.
• Trabajar siempre en main. Para cualquier cosa que no sea trivial, abre una rama: si sale mal, la borras y no ha pasado nada.
• Usar git reset --hard para «limpiar». Borra trabajo sin preguntar. En algo compartido, usa git revert.
• Consejo: git status y git diff antes de cada commit. Mirar lo que estás a punto de confirmar evita el 90 % de los sustos y de los ficheros colados por error.

Reescribe estos cuatro mensajes siguiendo las reglas vistas, e indica en cuál de ellos partirías el trabajo en más de un commit:

1. arreglos varios
2. Se ha modificado el fichero interfaz.py para que ahora el menú muestre también la opción de exportar y de paso he corregido un fallo en el cálculo del progreso
3. wip
4. añadida función

Marta arranca informes, un programa que lee el tareas.json de TareaFácil, guarda plantillas en plantillas/, genera PDF en salida/, usa un entorno virtual .venv y necesita una clave de la API de correo. Escribe su .gitignore explicando cada línea y di qué sí debe versionarse.

Describe, comando a comando, esta situación completa: creas la rama menu-corto, cambias ANCHO = 52 por ANCHO = 48 en interfaz.py y haces commit; mientras tanto, en main, otra persona cambió esa misma línea a ANCHO = 60 y confirmó. Fusiona, resuelve el conflicto dejando ANCHO = 48 y cierra la operación.

Solución 1.

El caso interesante es el segundo: mezcla dos ideas independientes, y eso tiene una consecuencia práctica muy concreta. Si mañana hay que deshacer la corrección del progreso, con un solo commit se llevaría por delante también la opción del menú. Un commit por idea es lo que hace que git revert sea una operación quirúrgica y no una demolición.

Solución 2.

Sí debe versionarse todo lo que es el proyecto y no un producto suyo: el código fuente, el README.md, el requirements.txt, la carpeta plantillas/ —porque las plantillas son parte del programa, no un resultado— y un .env.example con las claves vacías, que documenta qué variables hacen falta sin revelar ninguna. La regla que resume todo: versiona lo que escribes; ignora lo que se genera, lo que es personal y lo que es secreto.

Solución 3.

Tres detalles que conviene fijar. El conflicto no ha roto nada: hasta que no confirmes, el repositorio está en un estado intermedio del que se sale con git commit o del que se huye con git merge --abort. git add es la señal de «ya está resuelto», no una operación distinta. Y hay que revisar el fichero entero antes de confirmar, porque es fácil dejarse una marca >>>>>>> olvidada que convertiría el módulo en código con error de sintaxis.

Un sistema de control de versiones sustituye las carpetas _v3_bueno_definitivo por un historial real: instantáneas con fecha, autor y explicación, con la posibilidad de comparar, volver atrás y combinar el trabajo de varias personas. Git es distribuido, así que cada clon contiene la historia completa. Se configura una vez con git config --global user.name y user.email, que firman todos tus commits. Su modelo mental son tres zonas —directorio de trabajo, zona de preparación y repositorio—, y el recorrido de un cambio es siempre add → commit → (push). El día a día cabe en diez comandos: init, status, add, commit -m, log --oneline, diff, show, restore y rm, con git status como brújula permanente. Un commit es instantánea, mensaje, autor y padre, y su mensaje se escribe en imperativo, corto y explicando el porqué, con un commit por idea. El .gitignore deja fuera el entorno virtual, __pycache__, los datos locales, la configuración del editor y —esto sin excepciones— las credenciales, que permanecen en el historial aunque las borres después. Las ramas (branch, switch -c, merge, -d) permiten trabajar sin tocar la versión buena, y un conflicto no es una catástrofe: se edita el fichero dejando el contenido correcto, se borran las marcas <<<<<<<, ======= y >>>>>>>, se hace git add y se confirma. Para deshacer, restore con lo no confirmado y revert con lo ya confirmado —añade historia en vez de reescribirla—, dejando reset --hard para lo estrictamente local. Los remotos (clone, remote add, push, pull, fetch) llevan el proyecto a GitHub o GitLab, donde un pull request permite revisar el código antes de integrarlo. Y las etiquetas (git tag -a v1.0) fijan para siempre los números del versionado semántico.

TareaFácil es ahora la v0.20: un repositorio con su .gitignore, tres commits que explican qué se hizo y por qué, una etiqueta v0.19 y una rama fusionada y borrada. Puedes experimentar sin miedo, porque nada se pierde. Y sin embargo, hay algo que Git no puede decirte: si el código que acabas de confirmar funciona. Cada vez que tocas Agenda.ordenadas() o la validación de Tarea, sigues arrancando el menú y probando opciones a mano, una por una, rezando por no haber roto nada de lo que ya funcionaba. Eso es lento, es aburrido y se hace mal. En Pruebas automatizadas construirás la red de seguridad que faltaba: una carpeta tests/ con pruebas que comprueban solas, en un segundo, que todo sigue en su sitio.