Git y GitHub para principiantes: los comandos que vas a usar el 90% del tiempo

Si estas empezando a programar, seguro que ya te ha pasado: un curso o un tutorial te dice "instala Git y sube tu proyecto a GitHub", tu lo haces, y ahi se queda la cosa. Copias y pegas unos comandos, funciona (o no), y sigues sin tener ni idea de que acabas de hacer.

Este articulo no es una lista de comandos de Git. Es el flujo de trabajo real que vas a repetir casi todos los dias una vez empieces a programar en serio, explicado paso a paso.

Git no es GitHub (y esto es importante)

Antes de nada, una confusion muy tipica al empezar:

• Git es un programa que se instala en tu ordenador. Lleva un historial de los cambios de tu proyecto, en tu propio disco duro, sin necesidad de internet.
• GitHub es una web (propiedad de Microsoft) que guarda una copia de ese historial en la nube, para que puedas compartir tu codigo, hacer copias de seguridad o trabajar en equipo.

Podrias usar Git toda tu vida sin tocar GitHub. Pero como casi todo el mundo combina los dos, es donde suele empezar la confusion.

Antes de empezar: instalar y configurar Git

Si no lo tienes instalado, descargalo desde git-scm.com. Una vez instalado, abre una terminal (en Windows, la que uses normalmente) y dile a Git quien eres — esto solo se hace una vez por ordenador:

git config --global user.name "Tu Nombre"
git config --global user.email "tu-email@ejemplo.com"

Estos datos son los que apareceran como autor en cada cambio que subas. Usa el mismo email que tengas en tu cuenta de GitHub para que los commits se asocien bien a tu perfil.

El ciclo basico: init, status, add, commit

Vamos a la carpeta de un proyecto (puede estar vacia o tener ya archivos) y convertimos esa carpeta en un repositorio de Git:

cd mi-proyecto
git init

Esto crea una carpeta oculta .git donde Git va a guardar todo el historial. A partir de aqui, el ciclo que vas a repetir constantemente es este:

1. Ver que ha cambiado

git status

Te dice que archivos son nuevos, cuales has modificado y cuales todavia no esta "vigilando" Git.

2. Preparar los cambios que quieres guardar

git add nombre-del-archivo.js

O, para anadir todo lo que ha cambiado de golpe:

git add .

Este paso confunde a mucha gente al principio: git add no sube nada a ningun sitio, solo dice "esto es lo que quiero incluir en la proxima foto del proyecto".

3. Guardar esa "foto" con un mensaje

git commit -m "Anado el formulario de contacto"

Cada commit es un punto del historial al que puedes volver si algo se rompe mas adelante. Un buen habito desde ya: mensajes cortos pero que digan que cambia, no "cambios" o "arreglos" a secas — te lo vas a agradecer tu mismo dentro de tres meses.

Este ciclo —cambiar codigo, git add, git commit— es el que vas a repetir muchisimas veces al dia. Todo lo demas son variaciones sobre esto.

Subir tu proyecto a GitHub

Con el proyecto ya funcionando en local con Git, el siguiente paso es tener una copia en GitHub:

1. Entra en GitHub y crea un repositorio nuevo (boton "New repository"). No marques la opcion de crear un README si tu proyecto ya tiene archivos, para evitar conflictos.
2. GitHub te va a dar una URL parecida a https://github.com/tu-usuario/mi-proyecto.git. Conecta tu carpeta local con ese repositorio remoto:

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

3. Sube tu historial por primera vez:

git push -u origin main

El -u (de "upstream") solo hace falta la primera vez: le dice a Git que, a partir de ahora, cuando escribas simplemente git push, ya sabe a que repositorio y rama enviar los cambios.

A partir de aqui, tu dia a dia con un proyecto ya conectado a GitHub es:

git add .
git commit -m "Descripcion del cambio"
git push

Traer cambios: git pull

Si trabajas desde dos ordenadores, o en equipo con mas gente, necesitas el comando inverso a push: traer a tu ordenador los cambios que ya estan en GitHub pero no en tu copia local.

git pull

Buena costumbre: haz git pull nada mas sentarte a programar, antes de tocar nada, para partir siempre de la version mas reciente.

Ramas (branches): la parte que da mas respeto al principio

Una rama es una linea de trabajo independiente. La rama principal se suele llamar main. Cuando quieres probar algo sin tocar el codigo que ya funciona, creas una rama nueva:

git checkout -b nueva-funcionalidad

Esto crea la rama y te cambia a ella en un solo paso. Trabajas, haces tus commits normales (add, commit) dentro de esa rama, y cuando ya funciona, la juntas con la rama principal:

git checkout main
git merge nueva-funcionalidad

No hace falta dominar las ramas desde el primer dia, pero si entender la idea: te dejan experimentar sin miedo a romper lo que ya tenias funcionando.

El archivo que te va a salvar de un disgusto: .gitignore

Hay carpetas y archivos que nunca deberias subir a GitHub: la carpeta node_modules (se regenera con npm install), archivos .env con contrasenas o claves, o archivos temporales de tu editor.

Crea un archivo llamado .gitignore en la raiz del proyecto y escribe ahi, uno por linea, lo que Git debe ignorar:

node_modules/
.env
.DS_Store

Es mucho mas facil anadir esto desde el primer commit que intentar "sacar" un archivo con contrasenas despues de haberlo subido — una vez esta en el historial de Git, quitarlo del todo es bastante mas lioso.

Los errores mas tipicos al empezar

• Hacer commit sin haber hecho add antes: Git te avisa de que no hay nada que guardar. Recuerda: primero add, luego commit.
• Subir node_modules sin querer: repositorios de varios cientos de MB por una carpeta que se regenera sola. Usa .gitignore desde el principio.
• Mensajes de commit sin sentido ("asdf", "cambios2"): funciona igual, pero dentro de unas semanas no vas a tener ni idea de que hacia cada uno.
• Miedo a las ramas: usar solo main para todo tambien funciona al principio, pero en cuanto trabajes con mas gente (o quieras probar algo arriesgado), las ramas dejan de ser opcionales.

En resumen

El 90% de tu trabajo con Git se reduce a este ciclo:

git status
git add .
git commit -m "mensaje claro"
git push

Todo lo demas —ramas, merges, resolver conflictos— lo vas a ir aprendiendo sobre la marcha, cuando lo necesites de verdad. No hace falta memorizar treinta comandos antes de empezar: con esto ya puedes trabajar en cualquier proyecto real y llevar un historial decente de tus cambios.

Si todavia no tienes claro con que editor o herramientas montar tu entorno de programacion, echale un vistazo a nuestra guía de comandos de terminal básicos antes de seguir.

Una cosa más antes de que subas tu primer proyecto: si tienes claves de API o contraseñas en el código, no las subas a GitHub. Aquí te explico cómo protegerlas con variables de entorno antes de tu primer git push.