Programación Para Tontos


Si alguna vez subiste una carpeta `node_modules` completa (con sus 40,000 archivitos) a GitHub por accidente, esto es para ti. Si no, mejor, este tutorial te evita esa vergüenza pública.

## Paso 1: crea el archivo

En la raíz de tu proyecto, crea un archivo llamado exactamente `.gitignore` (con el punto al inicio, sin extensión).

```bash
touch .gitignore
```

## Paso 2: dile qué ignorar

```
# Dependencias
node_modules/

# Archivos de entorno con datos sensibles
.env

# Archivos generados por el sistema operativo
.DS_Store

# Carpetas de build
dist/
.next/
```

Cada línea es un patrón: `node_modules/` ignora esa carpeta completa, `.env` ignora ese archivo específico. Git va a fingir que esos archivos no existen para efectos de `git add` y `git status`.

## Paso 3: ¿y si ya subiste esos archivos antes?

`.gitignore` solo funciona para archivos que Git todavía no rastrea. Si ya los subiste por accidente, necesitas quitarlos del rastreo (sin borrarlos de tu computadora):

```bash
git rm -r --cached node_modules
git commit -m "Deja de rastrear node_modules"
```

`--cached` es la palabra clave aquí: borra el archivo del repositorio de Git, pero lo deja intacto en tu disco duro. Nadie pierde nada, excepto el peso muerto de tu repositorio.

## Paso 4: verifica que está funcionando

```bash
git status
```

Si `node_modules` ya no aparece en la lista de archivos nuevos o modificados, tu `.gitignore` está haciendo su trabajo correctamente.

## ¿Qué acabas de aprender?

- Para qué sirve el archivo `.gitignore` y cómo crearlo.
- Qué tipo de archivos deberías ignorar siempre (dependencias, archivos de entorno, builds).
- Cómo dejar de rastrear archivos que ya subiste por error con `git rm --cached`.


Configura un archivo .gitignore para mantener node_modules y archivos sensibles fuera de tu repositorio.

Tutorial: crea un .gitignore para no subir archivos basura


Un conflicto de merge pasa cuando Git no sabe cuál de dos cambios quedarte, porque ambos tocaron la misma línea. Suena aterrador la primera vez. No lo es. Vamos a provocar uno a propósito para perderle el miedo.

## Paso 1: crea el escenario del conflicto

```bash
echo "Versión original" > archivo.txt
git add archivo.txt
git commit -m "Versión original"

git checkout -b rama-a
echo "Cambio desde rama A" > archivo.txt
git commit -am "Cambio en rama A"

git checkout main
echo "Cambio desde main" > archivo.txt
git commit -am "Cambio en main"
```

Ahora tienes dos versiones distintas de la misma línea, en dos ramas distintas. Es hora de mezclarlas.

## Paso 2: intenta el merge

```bash
git merge rama-a
```

Git te va a mostrar algo como `CONFLICT (content): Merge conflict in archivo.txt`. No es un error fatal, es Git diciéndote "necesito que decidas tú".

## Paso 3: abre el archivo y decide

```
<<<<<<< HEAD
Cambio desde main
=======
Cambio desde rama A
>>>>>>> rama-a
```

Todo lo que está entre `<<<<<<< HEAD` y `=======` es tu versión actual. Todo entre `=======` y `>>>>>>> rama-a` es la versión que intentabas mezclar. Edita el archivo a mano, deja el contenido que quieras conservar, y borra esas líneas de marcado (`<<<<<<<`, `=======`, `>>>>>>>`).

## Paso 4: marca el conflicto como resuelto

```bash
git add archivo.txt
git commit -m "Resuelve conflicto entre main y rama-a"
```

Al hacer `git add` sobre el archivo editado, le dices a Git "ya decidí, este es el contenido final". El commit cierra el merge.

## ¿Qué acabas de aprender?

- Por qué ocurre un conflicto de merge (dos cambios en la misma línea).
- Cómo leer los marcadores `<<<<<<<`, `=======` y `>>>>>>>`.
- Que resolver un conflicto es solo editar el archivo y volver a hacer commit, nada mágico ni aterrador.


Aprende a leer y resolver un conflicto de merge en Git sin entrar en pánico.

Tutorial: resuelve tu primer conflicto de Git


Hasta ahora Git ha guardado tu historial solo en tu computadora. Hoy lo vas a respaldar en la nube (GitHub) para no perderlo si tu laptop decide morir en el peor momento posible.

## Paso 1: crea una cuenta y un repositorio en GitHub

Entra a [github.com](https://github.com/), crea una cuenta si no tienes una, y haz clic en "New repository". Ponle un nombre (por ejemplo, `mi-proyecto`) y NO marques la opción de agregar un README (ya tienes uno local).

## Paso 2: conecta tu repositorio local con GitHub

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

`origin` es simplemente un apodo (el más común) para la dirección remota de tu repositorio. Podrías llamarlo de otra forma, pero nadie lo hace, así que tampoco tú lo hagas.

## Paso 3: sube tus commits

```bash
git branch -M main
git push -u origin main
```

`-u` (de "upstream") le dice a Git "recuerda esta conexión", así que la próxima vez solo necesitas escribir `git push` a secas. La primera vez GitHub probablemente te pida iniciar sesión.

## Paso 4: verifica que funcionó

Recarga la página de tu repositorio en GitHub. Si ves tus archivos ahí, felicidades: tu código ya no depende únicamente de que tu computadora sobreviva.

## Paso 5: el flujo de todos los días

```bash
git add .
git commit -m "Describe qué cambiaste"
git push
```

Este es el ciclo que vas a repetir constantemente: guardas cambios localmente (`add` + `commit`) y luego los subes (`push`). Tan simple como suena, tan importante como parece.

## ¿Qué acabas de aprender?

- Cómo crear un repositorio remoto en GitHub.
- Cómo conectar tu proyecto local con `git remote add`.
- El flujo diario de `add`, `commit` y `push`.


Crea un repositorio en GitHub y sube tu proyecto local con git remote y git push.

Tutorial: sube tu primer proyecto a GitHub


Una rama (branch) es una copia paralela de tu proyecto donde puedes experimentar sin miedo a romper la versión "de verdad". Es como guardar tu partida antes de intentar algo arriesgado en un videojuego.

## Paso 1: revisa en qué rama estás

```bash
git branch
```

Vas a ver algo como `* main`, donde el asterisco marca la rama activa. `main` (o a veces `master`) suele ser la rama principal de tu proyecto.

## Paso 2: crea una rama nueva

```bash
git branch nueva-funcion
```

Esto crea la rama, pero no te mueve a ella todavía (es como crear una copia de seguridad sin abrirla).

## Paso 3: muévete a la rama nueva

```bash
git checkout nueva-funcion
```

O, en un solo paso (crear y moverte al mismo tiempo):

```bash
git checkout -b otra-funcion
```

`-b` le dice a Git "crea esta rama y muévete a ella de una vez". Ahora cualquier commit que hagas vive solo en esta rama, sin afectar `main` para nada.

## Paso 4: haz cambios y vuelve a `main`

```bash
echo "probando algo" >> notas.txt
git add notas.txt
git commit -m "Experimento en rama nueva"

git checkout main
```

Al volver a `main`, vas a notar que `notas.txt` no tiene esos cambios (¡porque viven en la otra rama!). Nada se rompió, nada se mezcló, todo sigue intacto.

## Paso 5: une los cambios cuando estés listo

```bash
git merge nueva-funcion
```

`merge` trae los cambios de la rama `nueva-funcion` hacia la rama en la que estás parado. Solo hazlo cuando estés seguro de que el experimento funcionó.

## ¿Qué acabas de aprender?

- Qué es una rama y por qué te deja experimentar sin miedo.
- Cómo crear y cambiar de rama con `git branch` y `git checkout`.
- Cómo unir los cambios de vuelta con `git merge`.


Aprende a crear y cambiar entre ramas de Git para experimentar sin arriesgar tu código principal.

Tutorial: crea tu primera rama (branch) sin miedo


Ya sabes qué es Git en teoría (revisa el artículo "Git y GitHub para principiantes" si no). Hoy lo vas a instalar de verdad y vas a hacer tu primer commit, sin dramas.

## Paso 1: instala Git

- **Windows**: descarga el instalador desde [git-scm.com](https://git-scm.com/) y sigue el asistente (dale "Next" a todo si no sabes qué elegir, las opciones por defecto son buenas).
- **macOS**: abre la terminal y ejecuta `git --version`. Si no está instalado, macOS te va a ofrecer instalarlo automáticamente.
- **Linux**: `sudo apt install git` (Ubuntu/Debian) o el gestor de paquetes de tu distribución.

## Paso 2: preséntate ante Git

```bash
git config --global user.name "Tu Nombre"
git config --global user.email "tu@correo.com"
```

Git necesita saber quién eres para firmar tus commits. No es un formulario burocrático, es una configuración que haces una sola vez por computadora.

## Paso 3: inicializa un repositorio

```bash
mkdir mi-proyecto
cd mi-proyecto
git init
```

`git init` convierte esa carpeta en un repositorio: a partir de ahora, Git va a poder llevar el historial de todo lo que pase ahí dentro.

## Paso 4: haz tu primer commit

```bash
echo "# Mi Proyecto" > README.md
git add README.md
git commit -m "Primer commit: agrego el README"
```

Acabas de crear tu primer "punto de guardado" oficial. Si algo sale mal en el futuro, siempre puedes volver a este momento exacto. Es, literalmente, un botón de "deshacer" con superpoderes y memoria perfecta.

## Paso 5: revisa el historial

```bash
git log
```

Vas a ver tu commit, con tu nombre, tu correo, la fecha y el mensaje que escribiste. Cada commit futuro se va a apilar aquí, contando la historia completa de tu proyecto.

## ¿Qué acabas de aprender?

- Cómo instalar Git y configurar tu identidad.
- Cómo inicializar un repositorio con `git init`.
- Cómo hacer tu primer commit con `git add` y `git commit`.


Instala Git en tu computadora y guarda el primer 'punto de guardado' de tu proyecto.

Tutorial: instala Git y haz tu primer commit


**Git** es una herramienta que guarda el historial de cambios de tu código, como un "control+Z" gigante con superpoderes. **GitHub** es un sitio web donde puedes guardar ese historial en la nube y compartirlo con otras personas.

## Los tres comandos que más usarás

```bash
git add .
git commit -m "Explica qué cambiaste"
git push
```

1. `git add .` — marca los archivos que cambiaste para guardarlos.
2. `git commit -m "..."` — guarda una "foto" de esos cambios con un mensaje.
3. `git push` — sube esa foto a GitHub para que quede respaldada.

## ¿Por qué debería usar Git desde el principio?

- Puedes deshacer errores sin miedo.
- Puedes ver exactamente qué cambió y cuándo.
- Es la forma estándar en la que trabajan los equipos de programación.

## Tu primer repositorio

1. Crea una carpeta para tu proyecto.
2. Ejecuta `git init` dentro de ella.
3. Crea una cuenta en GitHub y crea un repositorio nuevo.
4. Sigue las instrucciones de GitHub para conectar tu carpeta local con el repositorio remoto.

No necesitas entenderlo todo de una vez. Con estos tres comandos ya puedes empezar a versionar tus proyectos.


Aprende qué es Git, qué es GitHub, y los tres comandos que usarás el 90% del tiempo.

Git

Tutorial: crea un .gitignore para no subir archivos basura

Tutorial: resuelve tu primer conflicto de Git

Tutorial: sube tu primer proyecto a GitHub

Tutorial: crea tu primera rama (branch) sin miedo

Tutorial: instala Git y haz tu primer commit

Git y GitHub para principiantes: guía sin dramas