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

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 es un git checkout y en treinta segundos vuelves a cualquier punto del pasado.

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.

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 branch, git checkout -b), 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 8, 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.

Comprueba lo que sabes#