Control de versiones (Git fácil)

Git, GitHub y la nube

Git es local. Es un programa gratuito que se ejecuta en tu equipo y guarda el historial de versiones dentro de la propia carpeta, en la carpeta oculta .git. Activar el control de versiones no envía nada a internet ni pide ninguna cuenta: las versiones quedan solo en esta máquina — y si el disco falla o se pierde el equipo, se van con él.

GitHub es otra cosa: un servicio en la nube que guarda una copia del repositorio. Es a GitHub, o a un servicio parecido, adonde LightNote envía las versiones cuando sincronizas. Con esa copia fuera de aquí obtienes una copia de seguridad y puedes usar las mismas notas en otro equipo: en uno envías y en el otro recibes. GitHub es gratuito para uso personal, con repositorios privados ilimitados que solo tú ves.

En resumen: Git son las versiones, en tu equipo; el remoto es una copia de ellas en otro lugar — GitHub, otro servicio, una carpeta de OneDrive o de Google Drive, o un servidor tuyo. Mientras la carpeta no tiene remoto, el panel de control de versiones dice Versiones solo en este equipo. y ofrece el enlace Hacer copia de seguridad y sincronizar…, que se explica abajo.

Clonar un repositorio

Para trabajar en un repositorio que ya existe, usa Archivo → Clonar repositorio Git...; el elemento también está en la pantalla de inicio y en el panel de control de versiones de una carpeta que todavía no tiene repositorio. Pega la dirección HTTPS o SSH que muestra la página del repositorio; la URL de la propia página sirve, y un git clone ... copiado entero también. Elige la carpeta base y el nombre de la carpeta: el asistente muestra dónde se creará y avisa cuando ya hay algo ahí. En Opciones avanzadas están la rama, el clon superficial (solo el último commit) y los submódulos.

Cuando el servidor pide iniciar sesión, LightNote pregunta en una ventana: usuario y token, la frase de contraseña de la clave SSH, o la confirmación de la clave de un servidor que este equipo nunca vio; en ese caso la ventana muestra la huella digital y el enlace a la lista que publica el servicio, y lo predeterminado es no confiar. La respuesta va directo a Git y LightNote no la guarda; quien la guarda es el administrador de credenciales de Git, cuando está instalado (Git for Windows trae el Git Credential Manager). Confiar en la clave la escribe en ~/.ssh/known_hosts, como haría el propio ssh.

Si la clonación falla, la pantalla dice qué pasó y ofrece la salida: intentar por HTTPS cuando se rechazó la clave SSH, usar los certificados de Windows cuando el proxy de la empresa inspecciona HTTPS, descargar solo el último commit cuando la conexión se cae a mitad, o usar rutas largas cuando Windows no deja crear el archivo. Los Detalles técnicos traen el mensaje de Git, y lo que no se reconoce puede ir a la IA. Al terminar, el asistente abre la carpeta clonada en esta ventana o en una nueva.

Versionar la carpeta abierta

El control de versiones es opcional por espacio de trabajo. Habilítalo en Herramientas → Espacio de trabajo → Configuración del espacio de trabajo...: LightNote crea el repositorio Git (si aún no existe) y muestra la barra lateral de control de versiones (Ctrl+Shift+G).

En modo automático, LightNote guarda versiones (commits) por sí mismo en los momentos elegidos en los Ajustes generales (al guardar, al cerrar una pestaña o al cerrar la ventana). Durante la sesión, el commit lleva solo lo que escribió LightNote — lo que cambió una CLI de IA u otro programa queda pendiente, para que quien lo cambió haga su propio commit; Ctrl+S guarda la versión al momento, y lo que escribe el guardado automático entra en un commit cada 10 minutos. Al cerrar la ventana (activado por defecto), el commit lleva todo lo que cambió en la carpeta, incluso fuera de LightNote: es la red de seguridad del final de la sesión. En modo manual, escribes el mensaje y guardas la versión en el panel. El indicador de la barra de estado muestra el estado (sin cambios, X modificados…) y, al hacer clic, abre el menú de Git (ver abajo); en una carpeta que aún no tiene versionado, abre los ajustes del espacio de trabajo en Integraciones. Puedes ver el diff de cada archivo y restaurar (descartar) los cambios sin guardar.

La automatización tiene 3 niveles por carpeta (en Ajustes del espacio de trabajo): Manual (nada automático), Commit automático (guarda versiones por sí mismo, pero no sincroniza) y Todo automático (hace commit y sincroniza — push tras el commit + pull periódico; requiere credenciales de Git sin preguntar). El panel muestra una línea de estado con ↑ por enviar / ↓ por recibir respecto al remoto, y el botón principal cambia de commit a Sincronizar cuando hay versiones por enviar — así queda claro que, después de guardar, aún falta sincronizar.

El panel Git y el menú Git del árbol ofrecen Agregar (git add) y Restaurar (git restore) por archivo, y un único Ver qué cambió, que abre la pantalla de comparación. La lista del panel sigue el orden natural de las rutas, y el menú contextual de un archivo ofrece también Copiar... y Mostrar en el Explorador (deshabilitado para un archivo eliminado).

La pantalla de comparación muestra las dos versiones en paralelo, alineadas: los pasajes iguales quedan siempre uno frente al otro y cada lado muestra el número de línea de su archivo. Una línea cambiada aparece en ámbar, con la parte modificada resaltada dentro de ella. El botón Modo unificado cambia al formato de parche, Invertir los lados cambia la base de la comparación y F8 / Shift+F8 saltan de un cambio a otro.

El menú de Git en la barra de estado. En una carpeta con versionado, el indicador muestra la rama y, a su lado, lo que falta sincronizar (↓ por recibir, ↑ por enviar); el punto es verde con todo guardado en versión, ámbar con cambios pendientes y rojo con archivos en conflicto. Al hacer clic se abre un menú que empieza por el estado completo y ofrece Guardar versión de todo (commit)… — lleva todos los cambios de la carpeta, incluidos los de otros programas; con el mensaje en blanco, es automático —, Abrir el panel Git y, con un repositorio remoto, Sincronizar (recibir y enviar), Recibir (pull con merge), Enviar (push) y Comprobar el remoto (fetch). Recibir siempre fusiona (merge) y nunca hace rebase, sea cual sea la configuración de Git del equipo; si el merge tiene conflictos, el envío no se hace y el menú ofrece Deshacer el merge con conflicto…. En Acciones automáticas cambias el nivel de automatización de la carpeta sin abrir los ajustes. En Avanzado, Ejecutar comando git… ejecuta cualquier comando en la carpeta del repositorio y muestra la salida — sin terminal, así que un comando que pide escribir algo (editor de mensaje, contraseña en la consola) desiste en vez de esperar; para esos, usa la terminal. Si Git no está instalado, el clic abre la guía de instalación.

Mover y renombrar. Cuando mueves o renombras un archivo o una carpeta en LightNote (arrastrando en el árbol, cortando y pegando, renombrando), la versión lleva las dos mitades juntas y Git registra un cambio de nombre. Entra solo lo que ya estaba versionado; un archivo nuevo dentro de la carpeta movida espera, como los demás. Sigue la misma regla que Ctrl+S: con el commit al guardar desactivado, el movimiento espera el próximo commit. Los archivos grandes quedan fuera — consulta Archivos grandes y los límites de los servicios.

Historial y franja de cambios

La barra del editor de código y de la nota tiene dos botones para las versiones del archivo. Guardar versión guarda el archivo y conserva esta versión: en una carpeta versionada con Git hace un commit solo de este archivo — lo que otro programa o una sesión de IA cambió en los demás archivos queda fuera —, y fuera de un repositorio guarda un punto en el historial local. Se pone gris, con el motivo en la sugerencia, cuando nada cambió desde la última versión.

Versiones abre la lista de versiones del archivo abierto (la misma sección de la barra lateral), y su flecha ofrece Guardar versión con mensaje…, Ver qué cambió desde la última versión y Descartar los cambios desde la última versión…, que vuelve el archivo a la última versión, con o sin Git — el texto descartado queda en el historial local, y Ctrl+Z también lo recupera. La lista reúne los commits y los guardados locales: LightNote registra uno en cada Ctrl+S y, con el guardado automático, como mucho uno cada 10 minutos por archivo, además del archivo tal como estaba antes de la primera escritura — así que también funciona en una carpeta que no es un repositorio. Cada fila trae el asunto, el autor, cuándo fue y cuántas líneas entraron y salieron; el punto distingue un commit tuyo, un guardado del propio LightNote y un commit venido de una sesión de IA. Si hay cambios sin confirmar, son la primera fila. Hacer clic en una versión muestra qué cambió en ella; abrir la versión completa, comparar con la actual y comparar dos versiones marcadas están en el clic derecho.

Una franja de color en el margen marca las líneas cambiadas desde la última versión — en el editor de código y en la nota, y sigue lo que escribes: desaparece cuando deshaces hasta el original, sin esperar a guardar. La última versión es el último commit en el momento en que abriste el archivo — sin Git, el archivo tal como estaba al abrirlo. Guardar y el commit automático no la mueven: las marcas se quedan hasta que hagas clic en Guardar versión o cierres la pestaña. Para desactivarla usa Ver → Franja de cambios; desactivada no solo se oculta: no se calcula nada. Hacer clic en la franja muestra cómo estaba el fragmento, con Revertir este fragmento (Ctrl+Z lo deshace), Copiar original y Ver en el diff, que abre la comparación completa ya situada en esa línea. Cuando el archivo abierto cambia fuera de LightNote — una CLI de IA escribiendo en él, por ejemplo —, la pestaña sin cambios pendientes se recarga en silencio y la franja muestra lo que cambió; con cambios tuyos en otras partes, los dos se combinan (Ctrl+Z lo deshace); y si los dos tocaron las mismas líneas, una barra amarilla arriba de la pestaña ofrece Comparar, Quedarse con la del disco y Mantener la mía — hasta que elijas, el guardado automático no escribe ese archivo, y la versión que se va queda en el historial local. Una advertencia sobre el historial local: se guarda por ruta, así que renombrar el archivo pierde sus guardados locales — los commits de Git, no.

Autoría de la línea y cambio de rama

Quién escribió esta línea. En el menú de Git de la barra de estado, Autoría de la línea (blame) pone, al final de la línea del cursor, quién la escribió, cuándo y el resumen de la versión; por ejemplo, Ana · hace 3 días · corrige el total. Solo se anota la línea del cursor, y la anotación sigue al cursor. Una línea que aún no entró en ninguna versión dice Sin versionar; con cambios sin guardar, la anotación pide Guarde para ver la autoría, porque las líneas del archivo en disco ya no coinciden con las de la pantalla.

Cambiar de rama. El mismo menú tiene el submenú Rama: main (con el nombre de la rama actual), que lista las ramas locales: la actual viene marcada, y el clic en otra hace el cambio (git checkout). Crear rama… pide el nombre, lo comprueba antes de llamar a Git (sin espacios, sin .., sin empezar con -) y crea la rama a partir de la actual, ya trabajando en ella. El cambio queda desactivado mientras haya un archivo en conflicto o una sincronización en curso.

Copia de seguridad y sincronización: GitHub paso a paso

El enlace Hacer copia de seguridad y sincronizar… del panel — el mismo que Agregar repositorio remoto…, en el menú ⋯ del panel y en el menú de Git de la barra de estado — abre la pantalla Copia de seguridad y sincronización, con tres caminos: GitHub, el recomendado; Otro servicio; y una Carpeta sincronizada (OneDrive, Google Drive, Dropbox, un pendrive o una carpeta de red). Todos funcionan; GitHub es lo más sencillo para usar las notas en varios equipos y la copia de seguridad más segura. Para GitHub:

1. Crea la cuenta en github.com/signup: correo, contraseña y un nombre de usuario; GitHub envía un código para confirmar el correo. El plan Free basta.
2. Crea un repositorio en github.com/new: ponle un nombre (por ejemplo notas), marca Private y no marques Add a README, .gitignore ni licencia. Tiene que nacer vacío: con un README el primer envío se rechaza, porque GitHub ya tendría una historia que no es la tuya.
3. Copia la dirección HTTPS que muestra la página (algo como https://github.com/tu-usuario/notas.git) y pégala en Dirección del repositorio, en la pantalla de LightNote. Deja marcado Enviar las versiones ahora y haz clic en Conectar.
4. Inicia sesión: en el primer envío, Git abre una ventana de GitHub para que autorices en el navegador. Después Windows guarda el acceso — lo guarda el Git Credential Manager, que viene con Git para Windows — y no necesitas iniciar sesión otra vez.
5. En el otro equipo, instala Git y LightNote y usa Archivo → Clonar repositorio Git... con la misma dirección. A partir de ahí, Sincronizar recibe lo que envió el otro equipo y envía lo que hiciste aquí.

Para no tener que acordarte de sincronizar, elige Todo automático en los ajustes de la carpeta: LightNote envía después de cada commit y recibe de vez en cuando. Dos límites que conviene conocer: GitHub rechaza archivos de más de 100 MB y recomienda repositorios de hasta aproximadamente 1 GB — guarda los vídeos y archivos grandes fuera de la carpeta versionada. Y privado significa que solo tú (y quien invites) ves el repositorio, pero el contenido está en los servidores de GitHub: para lo confidencial, usa el Markdown seguro, que se cifra antes de salir del equipo.

En el móvil. Con el remoto conectado, Abrir en el móvil… (en el menú ⋯ del panel y en el menú de Git de la barra de estado) muestra un código QR. En LightNote del móvil, toque el nombre del espacio de trabajo y elija Leer el código QR del computador: el repositorio se convierte en un espacio de trabajo nuevo en el móvil. El QR lleva solo la dirección, nunca la contraseña: si el repositorio es privado, el móvil usa la cuenta Git que tenga para ese servidor o pide un token de acceso. El móvil clona por HTTPS: un remoto que es una carpeta de este computador (OneDrive, abajo) no le llega.

Archivos grandes y los límites de los servicios

Los límites. GitHub avisa a partir de 50 MB por archivo y rechaza los archivos de más de 100 MB; GitLab, Bitbucket y Azure Repos también rechazan los de más de 100 MB. Para el repositorio entero, GitHub recomienda hasta cerca de 1 GB (5 GB como máximo), y el plan gratuito de Bitbucket da 1 GB. Una carpeta sincronizada (OneDrive, Google Drive) no tiene ese techo.

Por qué el cuidado está en el commit. El límite vale para toda versión del historial, no solo para los archivos de hoy: si un archivo de 120 MB entra en una versión, el envío se rechaza — y sigue rechazado después de que borres el archivo, porque la versión antigua todavía lo contiene.

Qué hace LightNote. Un archivo de más de 100 MB queda fuera de toda versión que guarda la app — el commit automático, Ctrl+S, Guardar versión, el commit al cerrar la ventana, la instantánea y la sincronización del teléfono. Sigue en la carpeta, y un aviso ofrece Ignorar en Git (.gitignore). Por encima de 50 MB el archivo entra, con un aviso en la barra de estado. Un archivo marcado para Git LFS (que guarda solo un puntero en el repositorio) no se retiene.

Si el envío ya fue rechazado (la versión se guardó fuera de LightNote, en una terminal), el panel de Git lo dice. Borrar el archivo no lo resuelve. Si la versión aún no se envió, ejecuta reset @{u} en Avanzado → Ejecutar comando git… del menú de Git de la barra de estado: las versiones no enviadas se deshacen y los archivos quedan como están; pon el archivo grande en .gitignore y guarda la versión de nuevo. Para guardar el archivo en el repositorio, usa Git LFS (git-lfs.com).

Otros servicios, OneDrive/Google Drive y servidor propio

Otros servicios. Git funciona igual con cualquier servicio; solo cambia el lugar donde creas el repositorio. Los más conocidos: GitLab (gitlab.com, gratuito, con repositorios privados de hasta 10 GB cada uno), Bitbucket (bitbucket.org, gratuito hasta 5 usuarios, con 1 GB en total), Azure DevOps (dev.azure.com, de Microsoft, gratuito hasta 5 usuarios y con repositorios privados ilimitados) y Codeberg (codeberg.org, sin ánimo de lucro, pero solo para proyectos de código abierto — no sirve para notas privadas). Crea allí un repositorio vacío y privado, copia la dirección y elige Otro servicio en la pantalla Copia de seguridad y sincronización. Los límites de los planes cambian con el tiempo: consúltalos en el sitio de cada uno.

OneDrive, Google Drive o Dropbox, sin cuenta nueva. Elige Carpeta sincronizada y apunta a la carpeta del servicio en este equipo (por ejemplo C:\Users\tu-usuario\OneDrive o G:\Mi unidad). LightNote crea dentro un repositorio bare — una carpeta Notas.git que guarda solo las versiones, sin los archivos de trabajo — y lo usa como remoto; el servicio en la nube se encarga de copiar esa carpeta. En el otro equipo, espera a que la carpeta aparezca sincronizada y usa Archivo → Clonar repositorio Git..., pegando su ruta. La misma opción sirve para un pendrive o una carpeta de red, como copia de seguridad.

• ¿Por qué un repositorio bare y no toda la carpeta de notas dentro de OneDrive? La carpeta .git cambia todo el tiempo mientras trabajas, y dos equipos sincronizándola por la nube pueden corromperla. En el bare solo escribe el envío, y lo que graba ya no cambia después.
• Un equipo cada vez. Antes de trabajar en el otro equipo, espera a que OneDrive o Drive terminen de sincronizar; enviar desde los dos lados antes de eso puede crear copias en conflicto. Si pasa a menudo, GitHub es la salida más tranquila.
• Si la carpeta de trabajo ya está en la nube — Windows suele poner la carpeta Documentos en OneDrive —, la pantalla lo avisa. En un solo equipo, OneDrive hace de copia de seguridad; para usar las notas en varios, prefiere GitHub o saca la carpeta de notas de la nube y deja allí solo el bare.
• Sin Git también se puede: sincroniza toda la carpeta de notas con el servicio en la nube y deja el control de versiones apagado — el historial local sigue guardando las versiones de cada archivo. Es el camino de Tus notas en el móvil.

Un servidor propio. Para no depender de ninguna empresa, puedes alojar tu propio servidor Git. Gitea y Forgejo son ligeros, tienen una interfaz web parecida a la de GitHub y funcionan en Docker — en un equipo de casa, una Raspberry Pi, un NAS o un VPS alquilado. Lo más sencillo de todo es un servidor con SSH y un repositorio creado con git init --bare. El precio es cuidar del servidor: instalarlo, actualizarlo y hacer su copia de seguridad; las guías de instalación están en el sitio de cada proyecto. Con el servidor listo, la dirección del repositorio va en Otro servicio, como cualquier otra.