Git y GitHub: la diferencia

Una ferretería de Zaragoza encarga a un proveedor cambiar su página de servicios. La responsable comercial quiere comparar el texto anterior con la propuesta antes de aprobarla. El técnico necesita revisar el funcionamiento. Es un ejemplo ilustrativo con archivos ficticios, sin datos de pedidos ni resultados o ahorros medidos de una empresa real.

La pregunta de la ferretería es cómo conservar y revisar el trabajo. Git lleva el historial de las versiones registradas. GitHub añade un lugar compartido donde el proveedor puede presentar sus cambios y recibir comentarios. La responsable no necesita aprender órdenes para pedir una revisión comprensible: qué ha cambiado, por qué y qué queda pendiente. Aceptar un texto comercial y comprobar un formulario son decisiones distintas; conviene asignar un responsable a cada una.

Un repositorio reúne los archivos del proyecto y su historial. Guardar un archivo actualiza tu trabajo, pero no registra automáticamente una versión en Git. Un commit registra en el historial los cambios que has preparado, es decir, seleccionado para incluir en esa versión. Puedes comparar versiones registradas y consultar ese historial en el ordenador sin conexión. Si solo has ido guardando el archivo, no des por hecho que Git conserva cada estado anterior: los cambios sin confirmar pueden perderse.

Hacer push significa enviar los commits a otro repositorio, el destino remoto. Crear un commit local no hace ese envío por sí solo, aunque una integración puede encadenar ambas acciones. El destino tampoco tiene que ser GitHub: puede estar en otro servidor, en tu red o incluso en el mismo ordenador. Cuando alguien diga «ya está guardado», concreta si habla del archivo, de la versión registrada o de la copia enviada. Cada respuesta describe un estado distinto del trabajo.

Una rama es una línea de trabajo separada dentro del proyecto. Una solicitud de cambios propone integrar lo preparado en una rama dentro de otra. En la ferretería, el proveedor presenta la propuesta y las personas responsables revisan su parte. Comentar «pendiente de aprobación» expresa una decisión del equipo, pero para impedir la integración hace falta configurar una regla que la bloquee hasta recibir las aprobaciones exigidas. Esa diferencia importa cuando encargas el mantenimiento a alguien externo.

La protección de ramas permite exigir revisiones y comprobaciones antes de integrar. Con Free puedes aplicarla en repositorios públicos; para exigirla en los privados de una organización, valora Team. Revisa también las excepciones: determinadas restricciones no se aplican por defecto a administradores o a quienes pueden eludirlas. Pide al técnico que te enseñe la configuración y qué ocurriría con una propuesta rechazada. Deja por escrito quién debe resolverla antes de retomar el trabajo. Una aprobación tampoco demuestra que el formulario funcione: alguien debe comprobar el resultado antes de dar el cambio por bueno.

Un repositorio conserva lo que has registrado. No incluye automáticamente los cambios pendientes, los archivos excluidos ni todos los datos de otros servicios de tu empresa. Tener el código de la web en GitHub no demuestra que puedas recuperar los pedidos, el correo o cualquier otra información del negocio. Antes de dar una copia por suficiente, pregunta qué contiene y qué queda fuera. Una lista clara de lo que puedes recuperar resulta más útil que llamar «copia de todo» al repositorio.

Prepara también cómo vas a restaurar. GitHub documenta distintas vías para copiar el repositorio y otros datos, con alcances diferentes. Si eliges Forgejo propio, su información se reparte entre repositorios, base de datos, almacenamiento y configuración. El responsable técnico debe conservar las piezas necesarias de forma coherente. Pídele que explique qué recuperaría tras un fallo y qué necesita para hacerlo. La existencia de un archivo de copia, por sí sola, no responde a esa pregunta ni acredita que cubra el trabajo pendiente de registrar.

Usa archivos ficticios de una web o plantillas sin información de clientes. Encarga un cambio pequeño y pide ver la diferencia entre la versión anterior y la propuesta. No necesitas instalar todas las interfaces que encuentres: Git dispone de distintas formas de uso e integraciones. También puedes editar archivos desde la web de GitHub sin instalar Git en tu ordenador; el cambio se registra con un mensaje y queda sujeto a los permisos y protecciones del repositorio.

El siguiente paso es aprender a revisar el proyecto. Puedes acudir a Claude Code a fondo si vas a trabajar con una herramienta de programación. Para aclarar el vocabulario, tienes las explicaciones de repositorio, commit y rama. Si tu duda es cuándo pasa el resultado a estar accesible en internet, sigue con qué es publicar una web. El objetivo de la prueba es que puedas identificar qué ha ocurrido y qué decisión sigue en manos de una persona.