Skip to main content

Cuando Git necesita un hogar compartido: introducción a GitHub

Llegados a este punto, Git ya cumple su función esencial. El proyecto tiene historia, puedes volver atrás, corregir errores y trabajar con seguridad. Todo eso ocurre en tu máquina. Y mientras trabajas solo y en un único ordenador, es suficiente.

El siguiente problema aparece de forma natural, no teórica.

¿Qué ocurre cuando ese proyecto necesita salir de tu ordenador?

No porque Git sea insuficiente, sino porque el trabajo real no vive en una sola máquina ni en una sola persona.

El límite práctico de Git en local​

Un repositorio local es sólido, pero tiene límites claros:

  • Si el disco falla, la historia desaparece.
  • Si trabajas en dos ordenadores, no hay sincronización automática.
  • Si colaboras con otra persona, copiar carpetas deja de ser viable.
  • No existe un punto común donde todos miren la misma historia.

Aquí no falla Git. Falta un lugar compartido. Git resuelve el control del tiempo. GitHub resuelve el control del espacio compartido.

Qué es GitHub (y qué no es)​

GitHub es una plataforma que permite alojar repositorios Git en un servidor accesible por red.

Eso es lo esencial. Todo lo demás es accesorio. GitHub no sustituye a Git. GitHub no cambia cómo funcionan los commits. GitHub no decide por ti qué guardar.

Git sigue viviendo en tu ordenador. GitHub solo añade una idea nueva:

Existe una copia compartida del repositorio, accesible por varias personas.

Un error común es pensar que GitHub “hace Git”. No. GitHub alberga repositorios Git.

Repositorio local y repositorio remoto​

A partir de ahora conviene distinguir dos conceptos con claridad:

  • Repositorio local: vive en tu ordenador.
  • Repositorio remoto: vive en un servidor (GitHub).

Ambos son repositorios Git completos. Ninguno es “más Git” que el otro.

La relación entre ellos es explícita y voluntaria. No se sincronizan solos. Tú decides cuándo.

Git no empuja ni trae cambios automáticamente. Todo ocurre porque tú lo indicas.

Qué problema real resuelve GitHub​

GitHub aparece cuando necesitas una o varias de estas cosas:

  • Un respaldo externo del proyecto.
  • Acceder al mismo proyecto desde varios equipos.
  • Trabajar con otras personas sin copiar carpetas.
  • Tener un punto común de referencia para el equipo.

GitHub no introduce nuevas reglas. Introduce un lugar común.

Git controla la historia.

GitHub controla dónde vive esa historia compartida.

Crear un repositorio remoto vacío​

El uso más común al empezar es este: ya tienes un proyecto con Git en local y quieres publicar esa historia en GitHub.

Desde la interfaz web de GitHub se crea un repositorio nuevo, vacío, sin archivos. Ese repositorio no contiene historia todavía. Es solo un contenedor remoto.

Conceptualmente:

El repositorio remoto empieza sin recuerdos.

El local ya tiene historia.

El siguiente paso es conectarlos.

Conectar un repositorio local con GitHub​

La conexión se hace una sola vez. Git necesita saber dónde está el repositorio remoto.

Ejemplo real desde el proyecto local:

git remote add origin https://github.com/usuario/mi-proyecto.git

Aquí ocurre algo importante:

  • origin es solo un nombre simbólico.
  • La URL apunta al repositorio remoto.
  • No se sube nada todavía.

Puedes comprobar la conexión con:

git remote -v

Git ahora sabe que existe un lugar remoto, pero la historia sigue siendo local.

Publicar la historia por primera vez​

Subir el proyecto a GitHub no significa “activar GitHub”. Significa copiar la historia existente al repositorio remoto.

git push -u origin main

Este comando hace varias cosas a la vez:

  • Envía los commits locales al servidor.
  • Crea la rama main en el remoto.
  • Establece una relación por defecto entre local y remoto.

Después de esto, la historia existe en dos lugares.

Ese mismo historial ahora vive en tu máquina y en GitHub.

Traer cambios desde el repositorio remoto​

Cuando trabajas con más personas, o desde otro equipo, el flujo inverso es igual de importante.

git pull

Este comando no crea magia. Hace dos acciones claras:

  • Descarga cambios del repositorio remoto.
  • Los integra en tu repositorio local.

Git sigue siendo quien decide si hay conflictos y cómo resolverlos. GitHub solo entrega los datos.

Qué cambia realmente al usar GitHub​

A nivel mental, solo cambia una cosa:

El proyecto deja de depender de una sola máquina.

Todo lo demás sigue igual:

  • Sigues haciendo commits igual.
  • Sigues corrigiendo errores igual.
  • Sigues usando ramas igual.
  • Sigues decidiendo qué es importante.

GitHub no añade complejidad a Git. Añade visibilidad y acceso compartido.

Visualizar el modelo completo​

No hay acciones automáticas. Todo ocurre porque tú lo indicas.

Idea clave que debe quedar clara​

GitHub no es un paso “más avanzado”.

Es un paso lateral.

No aprendes un Git distinto. Aprendes a compartir el Git que ya sabes usar.

A partir de ahora, el proyecto tiene:

  • Historia.
  • Seguridad.
  • Copia externa.
  • Posibilidad real de colaboración.

Con esto, el terreno está preparado para el siguiente paso lógico: trabajar varias personas sobre la misma historia sin caos, usando GitHub como punto de encuentro, no como sustituto de Git.