# Git y GitHub desde cero para controlar versiones

**Categoría:** Programación · **Nivel:** Inicial · **Lectura:** 10 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/programacion/git-y-github-desde-cero/

## Respuesta rápida

**Git** es un sistema de **control de versiones**: guarda el historial completo de tu código, permite volver a cualquier versión anterior y deja que varias personas trabajen a la vez sin pisarse. **GitHub** es distinto: es un servicio en la nube donde se *alojan* repositorios de Git para guardarlos, compartirlos y colaborar (existen alternativas como GitLab). Es decir, Git es la herramienta que corre en tu equipo; GitHub, el lugar donde publicás lo que Git gestiona. El **flujo básico**, el que se usa casi siempre, son tres pasos: `git add` (elegir qué cambios guardar), `git commit` (guardar una versión con un mensaje que la describe) y `git push` (subirla a GitHub). Para trabajar sin romper nada se usan **ramas**: líneas de trabajo paralelas donde probás cambios sin tocar la versión estable, y luego se integran con una **solicitud de cambios** (*pull request*). Git no es opcional: es parte del oficio de programar.

## Qué es el control de versiones

Un **sistema de control de versiones** registra los cambios de un proyecto a lo largo del tiempo, de modo que puedas ver qué cambió, cuándo y quién lo hizo, y volver a cualquier estado anterior. La alternativa —carpetas llamadas `proyecto_final`, `proyecto_final_2`, `proyecto_final_definitivo`— es exactamente el caos que Git elimina.

> **Qué te da, en concreto**
>
> Una **máquina del tiempo**: cada versión guardada queda registrada y podés volver a ella. Una **red de seguridad**: si algo se rompe, volvés a la última versión que funcionaba. Y **colaboración sin pisarse**: varias personas trabajan en el mismo código a la vez, y Git combina los cambios. Estas tres cosas son la razón por la que Git está en prácticamente todos los proyectos de software del mundo.

## Git no es GitHub

Es la confusión número uno, y aclararla ahorra mucho lío:

|  | Git | GitHub |
|---|---|---|
| **Qué es** | Una herramienta que corre en tu equipo | Un servicio en la nube |
| **Qué hace** | Gestiona el historial de versiones | Aloja repositorios para compartir y colaborar |
| **Necesita internet** | No, funciona local | Sí, es un servicio en línea |
| **Alternativas** | Es el estándar de facto | GitLab, Bitbucket, otros |

Se puede usar Git sin GitHub (todo local), pero casi nadie lo hace: GitHub es donde vive tu [portafolio](../ruta-de-estudio-completa-para-aprender-a-programar/index.md), donde colaborás y donde se conectan herramientas como [la automatización de pruebas](../../testing/pruebas-automaticas-con-github-actions/index.md).

## El flujo básico

El 90 % del uso diario de Git son estos pasos. Dominarlos alcanza para trabajar; el resto se aprende cuando hace falta.

```bash
# Una sola vez por proyecto: iniciar el repositorio.
git init

# Ver qué cambió (lo usás todo el tiempo).
git status

# 1. Elegir qué cambios guardar (llevarlos al área de preparación).
git add archivo.js       # uno
git add .                # todos

# 2. Guardar una versión con un mensaje que la describa.
git commit -m "Agrega validación del formulario de contacto"

# 3. Subirla a GitHub (repositorio remoto).
git push

# Traer cambios que otros subieron.
git pull
```

Un **commit** es una versión guardada, un punto al que podés volver. Su **mensaje** importa: «arreglos varios» no dice nada; «Corrige el cálculo del total con envío» explica qué cambió y por qué, y tu yo futuro lo va a agradecer. El buen mensaje de commit es una forma de [código limpio](../clean-code-codigo-limpio-y-mantenible/index.md) aplicada al historial.

## Ramas: trabajar sin romper

Una **rama** (*branch*) es una línea de trabajo paralela. Te permite desarrollar una funcionalidad nueva o probar algo *sin tocar* la versión estable: si sale mal, descartás la rama y no pasó nada; si sale bien, la integrás.

```bash
# Crear una rama para una funcionalidad nueva y cambiarse a ella.
git switch -c nueva-funcionalidad

# ...trabajás, hacés add y commit en esa rama...

# Volver a la rama principal.
git switch main

# Integrar los cambios de la rama en main.
git merge nueva-funcionalidad
```

El patrón habitual: la rama `main` guarda siempre lo estable, y cada tarea se hace en su propia rama. Así, lo que está a medias nunca contamina lo que funciona. Es la misma idea que sostiene [GitOps](../../devops-cloud/gitops-con-kubernetes-y-argo-cd/index.md): el estado deseado vive en una rama controlada.

## Colaborar con solicitudes de cambios

Cuando varias personas trabajan, o cuando querés que revisen tu código antes de integrarlo, entra la **solicitud de cambios** (*pull request* en GitHub). El flujo:

1. **Trabajás en tu rama y la subís** Con push, la rama queda en GitHub.
2. **Abrís una solicitud de cambios** Proponés integrar tu rama en la principal, describiendo qué hiciste.
3. **Otros revisan y comentan** El equipo mira el código, sugiere cambios, y la automatización corre las pruebas.
4. **Se fusiona** Cuando está aprobada y las pruebas pasan, se integra a la rama principal.

Esta es la forma en que se colabora en casi todos los proyectos, incluidos los de código abierto: contribuir a un proyecto ajeno es, básicamente, abrir una solicitud de cambios. Y es donde se conecta con las [pruebas automáticas en GitHub Actions](../../testing/pruebas-automaticas-con-github-actions/index.md), que verifican cada solicitud antes de permitir la fusión.

## Errores frecuentes

- **Confundir Git con GitHub.** Git es la herramienta local; GitHub, uno de los lugares donde se publica.
- **Mensajes de commit inútiles.** «cambios» o «arreglos» no dicen nada; describí qué cambió y por qué.
- **Trabajar siempre en la rama principal.** Cada tarea en su rama mantiene `main` siempre estable.
- **Commits enormes.** Un commit por cambio lógico se entiende y se revierte mejor que uno con todo mezclado.
- **Subir secretos al repositorio.** Contraseñas y claves nunca van a Git; se excluyen con un archivo de ignorados.
- **No hacer pull antes de trabajar.** Empezar sin traer los cambios de otros genera conflictos evitables.
- **Asustarse con los conflictos.** Un conflicto de fusión es normal: Git marca las zonas en disputa y vos elegís.

## Preguntas frecuentes

**¿Cuál es la diferencia entre Git y GitHub?**
Git es un sistema de control de versiones que corre en tu propia computadora y gestiona el historial de cambios de un proyecto: guarda cada versión, permite volver atrás y combina el trabajo de varias personas, todo sin necesidad de conexión a internet. GitHub, en cambio, es un servicio en la nube que aloja repositorios de Git para guardarlos, compartirlos y colaborar, y del que existen alternativas como GitLab o Bitbucket. Dicho de forma simple, Git es la herramienta y GitHub es uno de los lugares donde se publica lo que esa herramienta gestiona. Se puede usar Git de forma totalmente local sin GitHub, pero en la práctica casi todo el mundo combina las dos cosas, porque GitHub es donde vive el portafolio, donde se colabora y donde se conectan herramientas de automatización.

**¿Qué es un commit?**
Un commit es una versión guardada de tu proyecto en un momento determinado: un punto en el historial al que siempre podés volver. Cada commit registra qué archivos cambiaron y viene acompañado de un mensaje que describe qué se hizo. El flujo para crear uno tiene dos pasos: primero se eligen los cambios que se quieren incluir llevándolos al área de preparación con el comando add, y luego se guardan de forma permanente con el comando commit y su mensaje. El mensaje importa mucho más de lo que parece: uno vago como «cambios» no le sirve a nadie, mientras que uno descriptivo como «corrige el cálculo del total con envío» explica qué cambió y por qué, lo que resulta invaluable cuando meses después alguien —incluido tu yo futuro— necesita entender el historial del proyecto.

**¿Para qué sirven las ramas?**
Las ramas permiten trabajar en algo nuevo sin tocar la versión que ya funciona. Una rama es una línea de trabajo paralela: en ella podés desarrollar una funcionalidad o experimentar con un cambio arriesgado, y si sale mal simplemente descartás la rama sin haber afectado nada, mientras que si sale bien la integrás en la rama principal. El patrón habitual es mantener la rama principal siempre en un estado estable y hacer cada tarea en su propia rama, de modo que lo que está a medias nunca contamine lo que ya está terminado y probado. Este esquema es la base de la colaboración en equipo, porque permite que varias personas trabajen en cosas distintas al mismo tiempo, cada una en su rama, sin pisarse entre sí, y que sus cambios se integren de forma ordenada y revisada.

**¿Qué es una solicitud de cambios o pull request?**
Es la forma de proponer que los cambios de tu rama se integren en la rama principal, dando lugar a que otros los revisen antes de fusionarlos. El flujo típico es: trabajás en tu propia rama, la subís a GitHub, y abrís una solicitud de cambios describiendo qué hiciste; entonces el resto del equipo puede mirar el código, comentar y sugerir mejoras, y la automatización puede correr las pruebas sobre ese cambio; cuando la solicitud está aprobada y las pruebas pasan, se fusiona en la rama principal. Es el mecanismo de colaboración estándar en prácticamente todos los proyectos, incluidos los de código abierto, donde contribuir consiste justamente en abrir una solicitud de cambios. Además, es el punto donde se conectan las pruebas automáticas, que verifican cada solicitud y pueden bloquear la fusión si algo falla.

**¿Qué hago si tengo un conflicto de fusión?**
No entrar en pánico: un conflicto de fusión es una situación normal, no un error grave. Ocurre cuando dos cambios modifican la misma parte de un archivo y Git no puede decidir por sí solo cuál conservar, así que te pide que lo resuelvas vos. Cuando pasa, Git marca en el archivo las zonas en disputa, mostrando la versión de cada lado, y tu tarea es editar esas zonas para dejar el contenido final que corresponde, eliminando las marcas. Luego se guarda el resultado con un commit y el conflicto queda resuelto. La mejor forma de tener menos conflictos es traer con frecuencia los cambios de los demás antes de empezar a trabajar y hacer commits pequeños y frecuentes, porque los conflictos grandes casi siempre vienen de ramas que se separaron durante mucho tiempo sin sincronizarse.

**¿Necesito aprender muchos comandos de Git?**
No para empezar a trabajar. Git tiene muchísimos comandos y opciones, pero el uso diario se concentra en un puñado que cubre la enorme mayoría de las situaciones: ver el estado del proyecto, preparar cambios, guardarlos en un commit, subirlos y bajarlos, y moverse entre ramas. Con eso alcanza para trabajar en proyectos reales desde el primer día. Los comandos más avanzados —para reescribir historial, recuperar trabajo perdido o resolver situaciones complejas— se aprenden cuando surge la necesidad concreta, no antes, y para entonces ya se tiene la base para entenderlos. El error habitual es querer dominar todo Git antes de usarlo, cuando lo eficaz es aprender el flujo básico, empezar a trabajar con él, y sumar lo demás a medida que aparece.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Consultas de la comunidad sobre Git, ramas y colaboración.
2. **Underc0de, foro.** [Sección Scripting](https://underc0de.org/foro/scripting/). Automatización y flujos de trabajo con la terminal.

### Documentación oficial

1. **Git.** [Pro Git](https://git-scm.com/book/es/v2). El libro oficial y gratuito, en español, referencia completa del control de versiones.
2. **Git.** [Documentación de Git](https://git-scm.com/doc). La referencia de los comandos citados.
3. **GitHub.** [GitHub Docs](https://docs.github.com/get-started). Cómo funciona la plataforma, los repositorios remotos y las solicitudes de cambios.
4. **GitHub.** [Autenticación](https://docs.github.com/authentication). Cómo conectar tu equipo con GitHub de forma segura.

## Guías relacionadas

- [Ruta de estudio completa](../ruta-de-estudio-completa-para-aprender-a-programar/index.md)
- [Depurar errores](../como-depurar-errores-de-programacion/index.md)
- [GitOps con Kubernetes](../../devops-cloud/gitops-con-kubernetes-y-argo-cd/index.md)
- [Pruebas en GitHub Actions](../../testing/pruebas-automaticas-con-github-actions/index.md)
- [Índice de Programación](../index.md)