Git y GitHub: en qué se diferencian y cómo se relacionan

Git y GitHub se confunden constantemente, aunque son cosas de distinto nivel. Git es un programa de control de versiones que instalas en tu ordenador: recuerda cada estado guardado del proyecto y te permite volver a él. GitHub es un servicio web que aloja copias de repositorios Git y alrededor de ellas ofrece herramientas para el trabajo en equipo. La forma más fácil de recordarlo: Git es el motor y GitHub es el taller donde puedes dejar ese motor y recibir servicios.

Qué es Git

Git es un sistema de control de versiones distribuido. Lo creó Linus Torvalds en 2005 para desarrollar el kernel de Linux, y desde entonces se ha convertido en el estándar del sector. Git funciona completamente en local: el historial de cambios se guarda en la carpeta oculta .git dentro del proyecto, y la mayoría de operaciones no necesitan internet.

La palabra «distribuido» es la clave. Cada participante del proyecto tiene en su ordenador una copia completa del repositorio con todo el historial, no solo los últimos archivos. Si el servidor desaparece, el proyecto se puede recuperar desde cualquier máquina de trabajo.

Lo que Git hace por sí solo:

• registrar cambios mediante commits, instantáneas del proyecto con autor, fecha y descripción;
• mostrar quién cambió una línea concreta, cuándo y por qué (git log, git blame);
• llevar líneas de desarrollo paralelas en ramas y fusionarlas;
• deshacer errores sin perder el resto del trabajo;
• intercambiar historial con otros repositorios mediante git push, git pull y git fetch.

Git es una herramienta de consola. Los clientes gráficos y los paneles integrados en los editores (VS Code, IntelliJ IDEA) no son más que capas sobre esos mismos comandos.

Qué es GitHub

GitHub es una plataforma en la nube para alojar repositorios Git; actualmente pertenece a Microsoft. Creas allí un repositorio, envías tu código local con git push y queda disponible para tus compañeros, para quien te contrate o para todo internet, si el repositorio es público.

Pero el valor de GitHub no está solo en el almacenamiento. Alrededor del repositorio añade lo que Git no tiene:

• Pull requests: solicitudes para fusionar una rama, con debate y revisión del código línea a línea;
• Issues: tareas e informes de errores vinculados al proyecto;
• GitHub Actions: CI/CD, es decir, ejecución automática de tests, compilación y despliegue en cada push;
• gestión de accesos: quién puede leer, escribir o fusionar en ramas protegidas;
• perfil de desarrollador: gráfico de actividad y proyectos públicos que miran los reclutadores;
• GitHub Pages: hosting gratuito de sitios estáticos directamente desde el repositorio.

Búsquedas como «git hub» o «git com» suelen referirse precisamente a este servicio, cuya dirección es github.com. La web oficial del propio Git es git-scm.com, desde donde se descarga el instalador.

Git y GitHub: tabla comparativa

Cómo trabajan juntos Git y GitHub

El vínculo entre ambos es el remote, el repositorio remoto. El repositorio local guarda la dirección del repositorio de GitHub con un nombre corto, por defecto origin. A partir de ahí el intercambio se hace con tres comandos:

• git push: enviar tus commits nuevos al servidor;
• git fetch: descargar los commits de otros sin tocar tus archivos;
• git pull: descargar e integrar en el acto los cambios en la rama actual (en esencia, fetch + merge o rebase).

Importante: GitHub no ve tu código hasta que lo envías. Un commit existe solo en local hasta el primer git push. De ahí el error típico de principiante: «he hecho commit y en GitHub no aparece nada».

El camino habitual: de un proyecto local a GitHub

# 1. Creamos el repositorio en local
cd my-project
git init
git add .
git commit -m "Primer commit"

# 2. Creamos un repositorio vacío en github.com (sin README),
#    copiamos su dirección y lo conectamos como remote
git remote add origin git@github.com:username/my-project.git

# 3. Renombramos la rama a main y la enviamos
git branch -M main
git push -u origin main

La opción -u (forma larga --set-upstream) vincula la rama local main con la remota. A partir de ahí basta con escribir git push y git pull sin argumentos.

El camino inverso: empezar desde un repositorio de GitHub

Si el proyecto ya está en GitHub, no se crea de nuevo, sino que se clona:

git clone https://github.com/username/my-project.git
cd my-project

El comando descargará todo el historial y configurará automáticamente el remote origin.

Autenticación: SSH o HTTPS

Desde 2021 GitHub no acepta la contraseña de la cuenta al trabajar con Git por HTTPS. Hay dos opciones que funcionan.

HTTPS + Personal Access Token. El token se crea en la configuración de la cuenta (Settings → Developer settings) y se introduce en lugar de la contraseña. Para no escribirlo cada vez, Git usa un gestor de credenciales; en Windows se instala junto con Git for Windows.

Claves SSH. La opción que las empresas esperan que sepas configurar por tu cuenta:

# Generamos la clave
ssh-keygen -t ed25519 -C "you@example.com"

# Mostramos la parte pública y la añadimos en GitHub:
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# Comprobamos la conexión
ssh -T git@github.com

Si todo va bien, GitHub responderá con un saludo que incluye tu usuario y la aclaración de que no ofrece acceso a shell; es lo normal. En este caso la dirección del repositorio debe usarse en formato git@github.com:user/repo.git, no https://.

Si el repositorio ya está conectado por HTTPS, puedes pasarlo a SSH con un solo comando:

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab y otros: diferencias

GitHub no es el único hosting para Git. Todos trabajan con el mismo Git, así que un repositorio se puede mover de uno a otro sin perder el historial. Se diferencian en las herramientas que ofrecen alrededor del código.

En GitLab la solicitud de fusión se llama merge request y en GitHub pull request, pero la idea es la misma: proponer los cambios de una rama y discutirlos antes de fusionarlos. La terminología cambia; los comandos de Git son idénticos.

Un repositorio local puede tener varios remotes a la vez; por ejemplo, para replicar el proyecto tanto en GitHub como en GitLab:

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

¿Necesito GitHub si trabajo solo?

Técnicamente no: Git funciona perfectamente en local. Pero un repositorio remoto tiene tres ventajas de peso incluso en un proyecto individual.

• Copia de seguridad. Si se estropea el portátil, el código y todo el historial siguen a salvo en el servidor.
• Trabajo desde varios dispositivos. En casa y en la oficina te sincronizas con push y pull.
• Portafolio. En procesos de selección para puestos junior, el perfil de GitHub a menudo se mira antes que el currículum: si hay proyectos vivos, mensajes de commit con sentido y README.

Por dónde empezar si eres principiante

No hace falta aprender Git y GitHub a la vez; el orden importa. Primero domina el ciclo local: git init, git status, git add, git commit, git log, ramas y fusiones. Cuando te salga sin chuleta, regístrate en GitHub, configura SSH y aprende push, pull y fetch. El último paso es el proceso en equipo: fork, rama por tarea, pull request y revisión.

Qué mira una empresa en tu GitHub

Los cuadraditos verdes de actividad no son lo principal. Un revisor con experiencia valora en un par de minutos otras cosas:

• mensajes de commit claros en lugar de «fix», «123» o «cambios»;
• commits pequeños y lógicos, no uno gigantesco tipo «subo el proyecto»;
• un README que explique cómo arrancar el proyecto;
• un archivo .gitignore: que en el repositorio no estén node_modules, un .env con contraseñas ni archivos del IDE;
• ramas y pull requests incluso en proyectos de práctica: demuestran que conoces el trabajo en equipo.

Errores típicos de principiante

«fatal: not a git repository»

Estás ejecutando un comando de Git fuera de un repositorio. Entra en la carpeta del proyecto o ejecuta git init. Registrarse en GitHub no tiene nada que ver: es un error local de Git.

«Permission denied (publickey)»

La clave SSH no se ha creado, no se ha añadido a GitHub o no está cargada en ssh-agent. Comprueba ssh -T git@github.com y la lista de claves en la configuración de la cuenta.

«rejected … (fetch first)» al hacer push

En el servidor hay commits que tú no tienes; por ejemplo, creaste el repositorio en GitHub con README. Trae primero los cambios con git pull --rebase origin main y repite git push. No uses --force mientras no sepas de quién es el trabajo que vas a sobrescribir.

Secretos en un repositorio público

Una contraseña o una clave de API que haya entrado en un commit se queda en el historial aunque después borres el archivo. Esa clave hay que regenerarla de inmediato, y el .env debe añadirse a .gitignore desde el principio.

Resumen

Git es la herramienta de control de versiones de tu ordenador, y GitHub es el servicio donde esos repositorios viven en la nube y donde se organiza el trabajo en equipo en torno a ellos. GitLab, Bitbucket y los demás son alternativas a GitHub, no a Git: por debajo todos tienen los mismos commits, ramas y comandos. Empieza por Git en local, luego conecta un remote y configura SSH. La conexión de un repositorio local con GitHub, push, pull y fetch se practican en el curso de Git.