Git vs GitHub: por qué no son lo mismo

Cuando empecé a enseñar Git, el mensaje que más se repetía era casi siempre el mismo: “no me funciona GitHub”. Al mirarlo, casi siempre GitHub no tenía nada que ver. El commit se había quedado a medias, o la persona ni siquiera había hecho un commit todavía. El problema estaba en su ordenador. Pero como llamaba “GitHub” a todo, nadie entendía qué le pasaba, y ella tampoco. Ese es el lío de mezclar git vs github: son dos cosas distintas, y si no las separas en tu cabeza, describes mal tus problemas y pides ayuda que no llega.

Para seguir este post no necesitas saber nada de Git todavía. Solo tener claro que estás escribiendo código en tu ordenador y quieres guardarlo de forma ordenada. Si además quieres instalarlo y dar tus primeros pasos, tienes la guía de primeros pasos con Git para arrancar de cero.

¿Git y GitHub son lo mismo?

No. Git es un programa que se instala en tu ordenador y GitHub es una página web. Ni siquiera los creó la misma gente.

La confusión tiene sentido porque casi siempre aparecen juntos: aprendes Git y a los diez minutos ya te están mandando crear una cuenta en GitHub. Se pronuncian parecido, comparten el nombre “git” y las dos tienen que ver con guardar código. Pero hacen trabajos diferentes. Una es la herramienta que guarda las versiones de tu proyecto. La otra es un sitio donde puedes dejar una copia de ese proyecto para tenerlo a salvo y compartirlo. Puedes usar la primera durante meses sin tocar la segunda.

Vamos una por una, porque entender qué hace cada una es lo que te va a ahorrar horas de frustración.

¿Qué es Git exactamente?

Git es una herramienta de control de versiones que corre en tu ordenador. Piensa en el historial de versiones de Google Docs, ese que te deja volver a como estaba el documento el martes pasado. Git hace eso mismo con tu código, pero con muchísimo más control y sin depender de internet.

Cada vez que llegas a un punto que quieres conservar, le pides a Git que haga una “foto” del estado actual de tus archivos. Esa foto se llama commit. Git guarda todas esas fotos en orden, con la fecha y un mensaje que tú escribes, dentro de una carpeta oculta llamada .git que vive en tu proyecto. Ahí está todo tu historial. En tu disco duro.

Mira el flujo básico, sin tocar internet en ningún momento:

# Crea un repositorio Git en la carpeta actual (aparece la carpeta oculta .git)
git init
# Le dices a Git qué archivo quieres incluir en la próxima foto
git add index.html
# Guardas la foto en el historial con un mensaje que la describe
git commit -m "Primera versión de la página"

Esas tres líneas versionan tu proyecto por completo. No hay ninguna cuenta, ningún login, ningún servidor. Si desconectas el wifi, funcionan exactamente igual. Eso es Git: guardar el historial de tu trabajo, en tu máquina. Y esa carpeta .git es tu repositorio de Git: la caja donde Git mete cada foto de tu proyecto.

Una precisión sobre commit: hay quien usa git commit -a para ahorrarse el git add. Ojo, porque -a solo incluye archivos que Git ya conocía de antes y has modificado o borrado. Un archivo nuevo que Git nunca ha visto no entra con -a; a esos tienes que pasarles git add la primera vez.

¿Qué es GitHub entonces?

GitHub es una plataforma web que aloja repositorios Git en internet. Es decir, un sitio donde subes una copia de ese repositorio que ya tienes en local para tenerlo guardado fuera de tu ordenador y, si quieres, compartirlo con otras personas.

La palabra clave es “copia”. GitHub no reemplaza a Git ni hace su trabajo. Lo que hace es recibir los commits que tú ya has creado con Git en tu máquina y guardarlos en sus servidores. Encima de eso añade cosas que solo tienen sentido cuando hay más de una persona o más de un ordenador: una web para ver el código con colorines, pull requests (una forma de proponer cambios y que otro los revise antes de aceptarlos), issues (una lista de tareas y errores del proyecto), permisos, y demás.

El momento exacto en que GitHub entra en escena es cuando conectas tu repositorio local con uno remoto y le envías tus commits:

# Registras la dirección del repositorio remoto y la llamas "origin"
git remote add origin https://github.com/tu-usuario/tu-repo.git
# Envías tus commits al remoto y enlazas tu rama main con esa copia
git push -u origin main

Fíjate en un detalle: los dos comandos empiezan por git. GitHub no tiene comandos propios. Sigues hablando con Git; lo único que cambia es que ahora Git manda tus commits a una dirección de internet. El paso de conectar el repositorio local con un remoto de GitHub tiene sus trampas, pero eso es harina de otro costal.

¿Qué significa que Git es “distribuido”?

Que cada clon de un repositorio es un repositorio completo, con todo el historial dentro. No hay un ordenador “principal” del que dependan los demás para funcionar.

Esto es distinto de sistemas más antiguos, donde había un servidor central que guardaba la historia de verdad y tu ordenador solo tenía la última versión. Si el servidor se caía, no podías ni ver los cambios de ayer. Con Git no pasa eso. Cuando clonas un proyecto de GitHub, no te bajas “la última versión”: te bajas el repositorio entero, con cada commit desde el primero. Puedes ver el historial, crear ramas, hacer commits y buscar en el pasado del proyecto con el avión en modo vuelo.

Esto tiene una consecuencia que a los juniors les cuesta creer al principio. Si mañana GitHub desapareciera de internet, tu trabajo seguiría intacto en tu ordenador, y en el de cada persona que hubiera clonado el proyecto. GitHub sería una copia más entre muchas, no la fuente de la verdad. La fuente de la verdad la tienes tú, en tu .git.

Git vs GitHub: qué hace cada uno

Esta tabla es la que te conviene tener clara antes de instalar nada:

	Git	GitHub
Qué es	Una herramienta de control de versiones	Una plataforma web para alojar repositorios
Dónde vive	En tu ordenador, en local	En internet, en los servidores de GitHub
Para qué sirve	Guardar el historial: commits, ramas, volver atrás	Alojar el repo, colaborar, pull requests, issues
¿Lo necesitas para versionar?	Sí, es lo que hace el trabajo	No, es opcional
Alternativas	Otros como Mercurial o Subversion, mucho menos usados hoy	GitLab, Bitbucket o tu propio servidor
Creado por	Linus Torvalds, el mismo del kernel de Linux	GitHub, Inc., hoy parte de Microsoft

Si tuvieras que quedarte con una sola fila, quédate con la cuarta. Git hace el trabajo de versionar. GitHub es un extra muy útil, pero un extra.

Antes de seguir, comprueba si de verdad tienes clara la separación. Este ejercicio te da situaciones concretas y te pide decidir si el protagonista es Git o GitHub:

Cargando ejercicio...

Si Git funciona sin GitHub, ¿para qué sirve GitHub?

Sirve para todo lo que Git en local no puede darte: una copia de seguridad fuera de tu ordenador y una forma de trabajar con otras personas sobre el mismo código.

Piénsalo así. Git en tu máquina es genial hasta que el disco duro muere, o cambias de portátil, o dos personas quieren tocar el mismo proyecto. Ahí es donde GitHub aporta:

• Copia de seguridad remota. Tus commits viven también en internet, así que un café derramado sobre el teclado no se lleva meses de trabajo.
• Colaboración de verdad. Varias personas hacen push y pull contra el mismo remoto sin pisarse, cada una desde su propio clon completo.
• Pull requests. Antes de meter un cambio al proyecto, alguien lo revisa, comenta línea a línea y lo aprueba. Es la parte social que Git no trae de fábrica.
• Issues y organización. Una lista compartida de errores, tareas y discusiones, pegada al código.

Ninguna de estas cosas es control de versiones. Todas son colaboración y alojamiento montados encima de Git. Por eso GitHub tiene tanto sentido en cuanto sales de tu proyecto en solitario, y por eso confundirlo con Git te despista sobre dónde está cada cosa.

¿GitHub es la única opción?

No, para nada. GitHub es la opción más conocida, pero es una entre varias. Como GitHub no forma parte de Git, cualquier sitio que sepa hablar el protocolo de Git puede alojar tus repositorios.

Las alternativas más habituales son GitLab y Bitbucket. Hacen básicamente lo mismo que GitHub: alojan tus repositorios remotos y añaden su propia versión de las pull requests, los permisos y las herramientas de equipo. También puedes montar tu propio servidor Git y no depender de ninguna empresa. Los comandos que escribes son idénticos en todos los casos. Cambia la dirección que pones en git remote add origin, y poco más.

La idea que quiero que se te quede: eliges dónde alojar tu repositorio, y GitHub es solo una de las opciones. Tu Git local no cambia según el sitio que elijas.

Errores comunes cuando confundes Git y GitHub

”No me funciona GitHub” cuando el problema es local

Es el más frecuente, con diferencia. Tu commit falla, tu git add no coge un archivo, tienes un conflicto sin resolver, y lo describes como “GitHub no me deja”. Quien te ayuda se va a mirar tu cuenta, tus permisos, tu conexión, y no encuentra nada, porque el problema está en tu ordenador. Antes de decir “GitHub”, pregúntate: ¿esto pasó al hacer commit (local, es Git) o al hacer push (contra el remoto, ahí sí puede entrar GitHub)?

Creer que sin GitHub no puedes usar Git

Puedes versionar un proyecto entero con solo git init, git add y git commit, sin cuenta ni remoto. GitHub es opcional, y lo repaso más abajo en las preguntas frecuentes.

Creer que GitHub guarda tus commits solo

Esto muerde a mucha gente. Haces commits durante días, das por hecho que están “en GitHub” y un día pierdes el portátil. Sorpresa: no había nada subido. GitHub no ve tus commits hasta que tú haces git push. El commit local y el envío al remoto son dos pasos separados, y el segundo lo lanzas tú a mano.

Decir “sube esto a Git”

Un detalle de vocabulario que delata la confusión. No “subes cosas a Git”: Git es local, no hay nada que subir. Lo que haces es un commit en Git y luego un push a GitHub. Cuando aprendes a nombrar bien cada paso, los errores de arriba prácticamente desaparecen solos, porque ya sabes en qué mitad del proceso estás.

Practica la diferencia con las manos

Leer la distinción entre Git y GitHub te da el modelo mental, pero se asienta cuando escribes tus propios commits, creas ramas y haces tu primer push. En el curso Git de cero a profesional practicas cada paso de forma interactiva, desde el primer git init hasta trabajar con un remoto, para que dejes de dudar dónde vive cada cosa.

Un concepto nuevo cada semana

Suscribirme

Preguntas Frecuentes

¿Puedo usar Git sin GitHub?

Sí, sin ningún problema. Git es una herramienta completa que corre en tu ordenador: creas el repositorio con git init, guardas versiones con git commit y tienes todo tu historial en local. GitHub solo entra si quieres una copia en internet o colaborar con otras personas. Muchos proyectos personales viven años sin subirse a ningún sitio.

¿Puedo usar GitHub sin saber Git?

En la práctica, muy poco. GitHub tiene una interfaz web que te deja crear archivos y hacer pequeñas ediciones sin tocar la terminal, y para leer código ajeno no necesitas saber Git. Pero en cuanto quieras trabajar de verdad, clonar un proyecto, hacer commits y enviar cambios, necesitas Git. GitHub aloja repositorios de Git, así que Git es el conocimiento base y GitHub va encima.

¿GitHub es gratis?

Sí, tiene un plan gratuito que a quien empieza le sobra para aprender y guardar sus proyectos. También hay planes de pago con extras pensados para empresas, y como sus condiciones cambian conviene mirar la web oficial de GitHub antes de decidir. Para empezar no pagas nada.

Si borro mi repositorio de GitHub, ¿pierdo mi trabajo local?

No. Tu trabajo vive en la carpeta .git de tu ordenador, con todo el historial. Borrar el repositorio de GitHub elimina la copia remota, no la tuya. De hecho podrías volver a crear el repositorio en GitHub y subir tu historial otra vez con un git push. Aquí se ve claro el modelo distribuido de Git: cada clon es completo por sí mismo.

¿GitLab y Bitbucket hacen lo mismo que GitHub?

En lo esencial, sí. Los tres alojan repositorios Git remotos y añaden colaboración: revisiones de cambios, permisos, herramientas de equipo. Cambian los detalles, la interfaz y algunas funciones concretas, pero el papel es el mismo, y los comandos de Git que escribes no cambian. GitHub es la opción más popular, no la única ni la obligatoria.