Git básico: clone, commit, push, pull

Ya te mueves por la terminal, y es justo desde ahí donde vive Git: todo lo de este capítulo se escribe en esa misma ventana. Vamos a darle un uso concreto.

Tienes el código de tu Team Builder en un fichero y has empezado a hacer cambios. Pasan dos días, algo deja de funcionar y no recuerdas qué tocaste. O peor: borraste un fichero sin querer. Sin Git esto es un problema real. Con Git, recuperarlo es un git restore y en treinta segundos lo tienes de vuelta tal como estaba.

Git no es una herramienta de subida de ficheros: es control de versiones. La diferencia es que cada cambio queda registrado, firmado y reversible. Eso te da algo valioso cuando estás aprendiendo: libertad para experimentar sin miedo.

El modelo mental: tres zonas y un remoto#

Antes de aprender comandos, aprende el mapa. Toda la confusión inicial con Git viene de no tener claro en qué zona está cada cosa.

 Tu máquina
 ┌─────────────────────────────────────────────────┐
 │                                                 │
 │  Working directory     Staging area    Local    │
 │  (tus ficheros)   ──► (bandeja de  ──► repo     │
 │                        salida)       (commits)  │
 │                                                 │
 │       git add ──►             git commit ──►    │
 └─────────────────────────────────────────────────┘
                                          │
                                    git push ▼
                               ┌──────────────────┐
                               │  Repositorio     │
                               │  REMOTO (GitHub) │
                               └──────────────────┘
                                    git pull ▲
                                          │
                               (cambios de otros)

• Working directory: donde editas. Tus ficheros normales, los que ves en el explorador.
• Staging area: una bandeja de salida. Aquí pones solo los cambios que quieres incluir en la próxima foto. No tienes que meter todo cada vez.
• Local repo: el historial en tu máquina. Cada git commit añade una foto a ese historial. No necesitas internet para hacer commits.
• Remoto (GitHub, GitLab…): otro repositorio, en un servidor. Es la copia compartida, el punto de encuentro entre tú y tu equipo, y tu copia de seguridad.

El flujo habitual es: editas → add → commit → push. Para traer cambios de otros: pull.

Los seis comandos del día a día#

git clone#

git clone https://github.com/tu-usuario/team-builder.git

Copia un repositorio remoto a tu máquina por primera vez. Solo se usa una vez por proyecto. Te crea la carpeta, descarga todos los ficheros y el historial completo, y configura automáticamente el “origin” (el nombre por defecto del remoto).

git status#

git status

Tu primer instinto ante cualquier duda. Te dice en qué zona está cada fichero modificado: rojo = en working directory pero fuera del staging, verde = en el staging listo para commitear. Úsalo antes y después de cada operación hasta que el modelo mental sea automático.

git add#

git add heroes.js          # un fichero concreto
git add src/               # toda una carpeta
git add .                  # todo lo modificado (con cuidado)

Mueve cambios del working directory al staging area. No guarda nada todavía: solo selecciona qué va a entrar en el próximo commit. Que puedas ser selectivo es una ventaja: si has tocado el componente de filtros y también el de gráficas, puedes hacer dos commits separados con mensajes distintos y el historial queda más claro.

git commit -m#

git commit -m "Añade filtro por rol en la tabla de héroes"

Hace la foto de lo que hay en el staging y la guarda en el historial local. El mensaje importa: sé descriptivo. “Cambios” o “fix” no sirven de nada dos semanas después. Un commit bien descrito es documentación gratuita.

El commit vive solo en tu máquina hasta que haces push. Sin internet puedes seguir commiteando con total normalidad.

git push#

git push

Envía tus commits locales al remoto. El flujo más común es: trabajas un rato, haces varios commits, y al final del día (o cuando terminas una funcionalidad) haces push para que quede en GitHub. Si algo le pasa a tu ordenador, tu trabajo está a salvo.

git pull#

git pull

Descarga los commits del remoto que aún no tienes en local y los fusiona con tu rama. Lo harás cada vez que empieces a trabajar para asegurarte de que partes de la versión más reciente, sobre todo si hay más gente en el proyecto.

Tu primer commit: lista de comprobación#

Sigue estos pasos la primera vez que empiezas un proyecto con Git:

Configura tu identidad (solo una vez en cada máquina):

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

Git firma cada commit con estos datos. Sin esto los commits no tienen autor.

Inicia el repositorio o clónalo:

# Opción A: proyecto nuevo en tu máquina
git init

# Opción B: ya existe un repo remoto (lo más habitual al empezar)
git clone https://github.com/tu-usuario/team-builder.git
cd team-builder

Edita un fichero (por ejemplo, añade una línea a README.md).

Comprueba el estado:

git status
# Verás el fichero en rojo: modificado pero sin stagear

Añádelo al staging:

git add README.md
git status
# Ahora aparece en verde: listo para el commit

Haz el commit:

git commit -m "Actualiza README con descripción del proyecto"

Si tienes un repositorio remoto configurado, sube los cambios:

git push

Abre GitHub y verás tu commit ahí. Eso es todo el flujo base.

La primera vez que haces push: autenticarte con GitHub#

Hay un detalle que frena a casi todo el mundo en su primer git push, y conviene saberlo de antemano para no quedarte atascado. Cuando subes a GitHub por HTTPS (la URL que empieza por https://github.com/...), GitHub necesita confirmar que ese repositorio es tuyo. Antes bastaba con teclear tu usuario y tu contraseña, pero desde agosto de 2021 GitHub ya no acepta la contraseña de la cuenta por HTTPS. Si lo intentas, el push falla con un error de autenticación y el trabajo se queda sin subir. No es que hayas hecho nada mal: falta el paso de identificarte, y hasta que no lo das, ningún push llega al remoto.

Tienes tres formas de resolverlo. Con cualquiera de ellas lo configuras una vez por máquina y te olvidas.

Opción A — GitHub CLI (la más cómoda para empezar). GitHub publica una herramienta de línea de comandos, gh, que hace todo el trámite por ti. La instalas desde cli.github.com y luego:

# arranca el asistente de inicio de sesión; abre el navegador para que confirmes
gh auth login

Respondes las preguntas (elige “GitHub.com” y, como protocolo, “HTTPS”), confirmas en el navegador y gh deja las credenciales guardadas. A partir de ahí, git push funciona sin volver a pedirte nada.

Opción B — Personal Access Token (PAT). Un token es una contraseña larga y aleatoria que generas en GitHub (en Settings → Developer settings → Personal access tokens) con permisos acotados. Cuando git push te pida usuario y contraseña, escribes tu usuario y pegas el token en lugar de la contraseña. El sistema operativo lo guarda —mediante el Git Credential Manager, que viene con la instalación de Git en Windows y macOS— para no pedírtelo en cada push.

Opción C — Clave SSH. En lugar de HTTPS, clonas y subes por SSH (la URL empieza por git@github.com:...). Generas un par de claves en tu máquina, registras la pública en GitHub, y las subidas se autentican solas con la clave privada, sin tokens ni contraseñas. Es el método que prefiere mucha gente cuando ya tiene soltura; para el primer día, la Opción A es la de menos fricción.

Cuál elijas no cambia nada de lo que ya has aprendido: el flujo add → commit → push es idéntico. Lo único que añades es ese paso de identificarte, una sola vez.

Qué no debe subir al repositorio: .gitignore#

Hay ficheros y carpetas que no quieres versionar. No porque sean secretos necesariamente, sino porque no tiene sentido: se generan solos, son enormes o contienen datos que no deben salir de tu máquina.

.gitignore es un fichero de texto en la raíz del proyecto que le dice a Git qué ignorar. Lo creas tú, una sola vez, y desde ese momento Git actúa como si esos ficheros no existieran.

Un ejemplo típico:

node_modules/
.env
dist/

Qué significa cada línea:

• node_modules/: la carpeta donde viven las dependencias de un proyecto. En niveles posteriores aprenderás qué son exactamente, pero por ahora quédate con esto: puede pesar cientos de megabytes, se regenera con un comando, y subirla al repo no aporta nada a nadie. Todos los que trabajen contigo la generan en su propio ordenador.
• .env: un fichero donde se guardan contraseñas, claves de acceso a servicios y otros secretos de configuración. Subir esto al repo es un error grave: esos datos quedan públicos para siempre en el historial, aunque después los borres.
• dist/: la carpeta que se genera cuando compilas o construyes el proyecto. Como con node_modules/, se puede regenerar; no necesitas versionarla.

Para crear el fichero, basta con abrir un editor y guardarlo como .gitignore en la raíz del proyecto. Git lo detecta automáticamente.

El momento de crearlo es al inicio, antes del primer commit. Si después de hacer varios commits te das cuenta de que subiste algo que no debías, hay forma de arreglarlo, pero es más trabajo. Mejor hacerlo bien desde el principio.

Puedes comprobar que funciona con git status: los ficheros listados en .gitignore no aparecerán, ni en rojo ni en verde. Para Git, no existen.

Una nota honesta sobre lo que no cubre este capítulo#

Lo que has visto es el flujo de una sola persona trabajando en una sola rama. Eso es suficiente para empezar y para proyectos personales.

En cuanto trabajes en equipo o empieces a gestionar funcionalidades en paralelo, necesitarás ramas (git switch para cambiar de rama, git switch -c para crear una), pull requests para revisar código antes de fusionarlo, y a veces resolver conflictos cuando dos personas tocan el mismo fichero. También existe git rebase para un historial más limpio. Todo eso llega en el Nivel 9, cuando ya tengas soltura con lo básico. No te adelantes: el flujo de hoy ya te saca de más del ochenta por ciento de los problemas.

Si buscas tutoriales por tu cuenta, verás git checkout para casi todo: cambiar de rama, crear ramas, descartar cambios. Sigue funcionando, pero desde Git 2.23 (2019) ese comando se partió en dos más claros: git switch para moverte entre ramas y git restore para descartar cambios del working directory y volver a la última versión guardada. Cuando veas git checkout en código o guías antiguas, ya sabes que switch y restore son su versión moderna.

Comprueba lo que sabes#