Git y GitHub no son lo mismo: qué hace cada uno

Publicado el 2026-09-12 por frfrand

Uno es un programa que corre en tu máquina; el otro es un servicio con una copia de tu repositorio y un montón de cosas alrededor. Dónde termina uno y empieza el otro, y por qué importa.

Es una confusión tan común que vale separarla bien, porque saber dónde termina uno y empieza el otro evita bastantes malentendidos.

Git es un programa

Git es un sistema de control de versiones que corre en tu computadora. Lo instalás, y a partir de ahí podés crear repositorios, hacer commits, ramas, fusiones y ver la historia completa.

Todo eso funciona sin conexión a Internet y sin ninguna cuenta en ningún lado. Un repositorio de Git es una carpeta oculta llamada .git dentro de tu proyecto. Ahí está todo.

Lo escribió Linus Torvalds en 2005, en unas semanas, porque el sistema que usaban para el kernel de Linux dejó de ser gratuito. Los objetivos eran velocidad, integridad y buen soporte para trabajo en paralelo.

GitHub es un servicio

GitHub es una empresa que aloja repositorios de Git y les agrega cosas alrededor.

La parte de "alojar" es la más simple: tiene una copia de tu repositorio, accesible por la red, para que varias personas trabajen contra el mismo lugar.

Lo que agrega encima es lo que la hizo grande, y nada de eso es parte de Git:

• Pull requests, para revisar cambios antes de integrarlos
• Issues, para seguir tareas y errores
• Actions, para ejecutar procesos automáticos
• Permisos, equipos y organizaciones
• La interfaz web para leer código

Hay alternativas que hacen lo mismo: GitLab, Bitbucket, Gitea, Forgejo. Y también podés alojar tu repositorio en un servidor propio por SSH sin ninguna plataforma: alcanza con un repositorio vacío al que hacer push.

Qué quiere decir "distribuido"

Esta es la parte que más cuesta cuando uno viene de sistemas anteriores.

Cada copia de un repositorio de Git contiene la historia entera. No hay un servidor central que sea "el original" y copias parciales.

Consecuencias prácticas:

• Podés trabajar, hacer commits, crear ramas y ver toda la historia sin conexión.
• Si GitHub desaparece mañana, tu repositorio local tiene todo. Perderías los issues y los pull requests, que sí son de GitHub, pero no el código ni la historia.
• Podés tener varios remotos a la vez.

Que GitHub sea "el principal" es una convención del equipo, no una propiedad técnica.

Los remotos, en concreto

Un remoto es simplemente un nombre para una dirección:

git remote -v origin git@github.com:empresa/proyecto.git (fetch) origin git@github.com:empresa/proyecto.git (push)

"origin" no tiene nada de especial: es el nombre por defecto que se le pone al primero. Podés agregar otro:

git remote add produccion deploy@miservidor.com:/repos/app.git git push produccion main

Ese fue, durante años, el mecanismo de despliegue más simple que existía: hacer push directamente a un repositorio en el servidor, con un hook que actualizaba el sitio.

Dónde encaja el despliegue

Hoy el flujo más común es: vos hacés push a GitHub, GitHub avisa a tu servidor mediante un webhook, y el servidor baja el código y lo despliega.

Esa distinción aclara un punto que confunde: tu servidor no está mirando GitHub. Es GitHub el que le avisa. Por eso, cuando un despliegue no se dispara, el primer lugar donde mirar es el historial de entregas del webhook: ahí se ve si el aviso salió y qué respondió el servidor.

En ArduMaker se configura justamente así: vinculás el repositorio, elegís la rama, y cada push dispara el build y el reinicio, con su log para saber en qué paso quedó.