Cómo versionar proyectos con Git

Trello, Notion y ClickUp tienen un "historial de actividad", pero es un historial que ellos controlan. Vive en su servidor, en su formato, con la retención que decidan. Si mañana cambian los términos, limitan el historial a los últimos 30 días en el plan gratis, o simplemente cierran el servicio, tu historial de cambios desaparece con ellos.

Para equipos técnicos esto es un problema conocido — porque ya resolvieron exactamente el mismo problema con el código hace años. La respuesta se llama Git: un sistema de control de versiones distribuido donde el historial vive en tu propio disco, no en un servidor de terceros.

La pregunta que este post responde es simple: ¿se puede aplicar la misma lógica a la gestión de proyectos? Sí, pero solo si la herramienta lo permite a nivel de arquitectura.

Esto no es una integración de Hito con Git. No hay un botón "conectar a GitHub" dentro de la app, y es importante ser honestos al respecto. Lo que sí existe es una arquitectura de storage que hace que Git funcione de forma natural, sin ningún trabajo extra:

• Hito guarda tu workspace como una carpeta de archivos .json planos, no en una base de datos propietaria.
• Cada entidad es su propio archivo: cada proyecto vive en projects/{id}.json, cada checklist en checklist-templates/{id}.json, y así con cada colección (productos, tipos de proyecto, procesos, automatizaciones, trimestres).
• Hay un workspace.json en la raíz con la configuración general.
• Todo esto se valida con esquemas antes de guardarse, así que los archivos son consistentes y legibles con cualquier editor de texto.

En otras palabras: Git no es una feature que Hito construyó. Es una consecuencia directa de ser local-first — tus datos ya están en un formato que cualquier herramienta de versionado puede leer. Puedes verificarlo tú mismo: el código de Hito es público y auditable en GitHub.

Estos son los pasos reales, usando comandos estándar de Git — no hace falta ninguna herramienta adicional.

1. Conecta Hito a una carpeta local. Si usas Chrome, Edge o Brave, Hito te deja elegir la carpeta directamente desde el navegador (File System Access API). Si usas Firefox o Safari, exporta/importa archivos manualmente. En ambos casos, termina existiendo una carpeta real en tu disco.
2. Abre una terminal en esa carpeta e inicializa el repositorio:

   cd /ruta/a/tu/workspace-hito
   git init

3. Crea un .gitignore para excluir lo que no aporta al historial (ver sección siguiente).
4. Haz tu primer commit:

   git add .
   git commit -m "Estado inicial del workspace"

   Este commit es tu línea base. A partir de acá, cada cambio que hagas en Hito —crear una tarea, mover una tarjeta, editar un proceso— queda disponible para que lo confirmes con git add y git commit cuando quieras.
5. Revisa cambios antes de confirmarlos:

   git status
   git diff

   Como cada tarea es un archivo JSON individual, git diff te muestra exactamente qué campo cambió — el status de una tarea, un comentario nuevo, una fecha de vencimiento— igual que verías el diff de una línea de código.
6. Consulta el historial completo cuando lo necesites:

   git log --oneline -- projects/

   Esto te da un historial real, con autor, fecha y mensaje de cada cambio — algo que ninguna app cloud te da con este nivel de detalle y control.
7. Marca hitos importantes con tags (por ejemplo, el cierre de un sprint o la entrega a un cliente):

   git tag -a cierre-q1-2026 -m "Cierre de proyectos Q1"

8. Comparte el repositorio con tu equipo si quieres colaboración con historial compartido: puedes usar un remoto privado (GitHub, GitLab, Gitea autoalojado) y trabajar con git pull / git push como con cualquier repo de código. Si no quieres un servidor remoto, una carpeta compartida por red también funciona — el historial de Git vive dentro de la propia carpeta.

Un .gitignore razonable para un workspace de Hito:

.backups/

Hito crea automáticamente una carpeta .backups/ con snapshots previos a migraciones de esquema (por ejemplo, cuando actualizas de versión y el formato de un archivo cambia). Una vez que tienes Git llevando el historial real, esos snapshots automáticos son redundantes — Git ya te permite volver a cualquier estado anterior con más precisión. Esta es una recomendación práctica nuestra, no un requisito de Hito: si prefieres conservar ambos, no pasa nada.

Si dos personas usan la misma carpeta sin coordinarse, pueden pasar conflictos de merge — como con cualquier repo de Git. La buena noticia es que la arquitectura de "un archivo por entidad" reduce mucho el riesgo: si tú editas la tarea A y tu compañero edita la tarea B, son dos archivos distintos y Git los combina sin problema.

El conflicto real aparece cuando dos personas editan la misma tarea o el mismo proceso en paralelo sin sincronizar. Ahí sí vas a tener que resolver el conflicto manualmente, igual que harías con un archivo de código. Para equipos que editan mucho en simultáneo sobre las mismas entidades, un sync en tiempo real (Dropbox, Google Drive) evita esta fricción mejor que Git.

Versionar proyectos con Git deja de ser una idea exótica en cuanto la herramienta que usas guarda tus datos como archivos abiertos. En Hito no hace falta ninguna integración especial: tu workspace ya es una carpeta de JSON planos, así que git init y un primer commit son suficientes para empezar a tener el mismo control de versiones que ya usas en tu código.

Si quieres probarlo, instala Hito, conecta una carpeta y corre los ocho pasos de esta guía — vas a tener historial real de tus proyectos en menos de cinco minutos.

Sobre Hito: Gestión de proyectos, procesos y checklists 100% local-first. Open source (MIT), sin nube, sin cuenta, sin suscripción. Pruébalo gratis →