Repositorio local y commits

Para entender los commits, hay que visualizar primero las tres zonas por las que Git hace transitar tus archivos.

Analogía: preparar un paquete. El directorio de trabajo es tu escritorio desordenado; la zona de staging es la caja donde pones lo que quieres enviar; el commit es el momento en que sellas la caja y la archivas.

Para transformar una carpeta ordinaria en repositorio Git:

# Situarse en la carpeta del proyecto
cd mon-projet

# Inicializar el repositorio
git init

Eso crea una subcarpeta oculta .git/ que contiene todo el historial y la configuración del repositorio.

# Verificar el estado del repositorio recién creado
git status

⚠️ Nunca borres la carpeta .git/: contiene todo el historial. Borrarla equivale a perder el versionado (pero no tus archivos actuales).

🔧 Mini-ejercicio — Escribe el comando que transforma la carpeta actual en repositorio Git, luego el que muestra su estado.

git init
git status

Un archivo puede estar seguido (tracked) o no seguido (untracked) por Git.

# Preparar un archivo preciso
git add fichier.txt

# Preparar todos los cambios de la carpeta
git add .

# Ver el estado (seguido / no seguido / preparado)
git status

git status es tu mejor amigo: úsalo antes y después de cada git add para ver exactamente lo que Git se dispone a registrar.

🔧 Mini-ejercicio — Acabas de modificar index.html y style.css. Escribe el comando que prepara (stage) solo index.html.

git add index.html

Un commit es una instantánea (snapshot) de tu proyecto en un instante dado, acompañada de un mensaje que explica el cambio.

# Preparar y luego registrar
git add .
git commit -m "Añade la página de inicio"

Cada commit posee:

# Ver el historial de los commits
git log
git log --oneline   # versión compacta

Un buen commit es atómico: hace una sola cosa coherente. Evita el commit cajón de sastre «un montón de cosas» — prefiere varios commits pequeños y claros.

🔧 Mini-ejercicio — Prepara todos tus cambios y crea un commit cuyo mensaje sea «Añade la página de contacto».

git add .
git commit -m "Añade la página de contacto"

El mensaje de commit cuenta la historia del proyecto. Un buen mensaje ahorra horas a todo el equipo (y a ti mismo dentro de 6 meses).

Reglas de base

• Escribir en imperativo presente: «Añade…», «Corrige…», «Elimina…».
• Una línea de resumen corta (≤ 50 caracteres), luego un cuerpo detallado si hace falta.
• Explicar el porqué, no solo el qué.

Comparación

Convención habitual (Conventional Commits)

feat: añade la autenticación por token
fix: corrige la paginación de los resultados
docs: completa el README de instalación

Truco mnemotécnico: un buen mensaje debe completar la frase «Si aplico este commit, va a…». Ejemplo: «…añadir la página de inicio».

Algunos archivos nunca deben versionarse: archivos temporales, dependencias voluminosas, secretos, archivos compilados. El archivo .gitignore indica a Git que los ignore.

# Ejemplo de contenido de un archivo .gitignore
target/
node_modules/
*.log
.env
.DS_Store

⚠️ Regla de oro de seguridad: nunca hagas commit de contraseñas, claves API o secretos. Una vez en el historial Git, un secreto se queda — aunque lo borres después. Pon .env en .gitignore desde el principio.

🔧 Mini-ejercicio — Escribe la línea a añadir en un .gitignore para impedir que Git versione el archivo de secretos .env.

.env

Question 1: ¿Qué comando transforma una carpeta ordinaria en repositorio Git?

a) git start

b) git init

c) git new

d) git create

Question 2: ¿Cuál es el orden correcto de las tres zonas de Git?

a) Repositorio → staging → directorio de trabajo

b) Directorio de trabajo → staging → repositorio local

c) Staging → repositorio → directorio de trabajo

d) Directorio de trabajo → repositorio → staging

Question 3: ¿Para qué sirve git add?

a) Para crear un commit

b) Para preparar cambios en la zona de staging

c) Para borrar un archivo

d) Para enviar el código a GitHub

Question 4: ¿Cuál es un buen mensaje de commit?

a) truc

b) wip

c) Corrige el crash al arrancar si falta la config

d) .

Question 5: ¿Por qué usar un .gitignore?

a) Para acelerar el ordenador

b) Para impedir que Git versione ciertos archivos (temporales, secretos, dependencias)

c) Para borrar el historial

d) Para ignorar los commits

Consigna

Crea un repositorio local, añade un archivo, ignora un archivo secreto, y haz dos commits limpios.

Corrección — Secuencia de comandos esperada

# 1. Crear y entrar en la carpeta
mkdir mon-premier-depot
cd mon-premier-depot

# 2. Inicializar el repositorio
git init

# 3. Crear un archivo de contenido y un .gitignore
echo "# Mi proyecto" > README.md
echo ".env" > .gitignore
echo "SECRET=123" > .env        # este archivo debe ignorarse

# 4. Verificar el estado (.env NO debe aparecer)
git status

# 5. Primer commit
git add README.md .gitignore
git commit -m "Inicializa el proyecto con README y gitignore"

# 6. Modificar y segundo commit
echo "Descripción del proyecto" >> README.md
git add README.md
git commit -m "Completa la descripción en el README"

# 7. Consultar el historial
git log --oneline

Resultado esperado:

b2c3d4e Completa la descripción en el README
a1b2c3d Inicializa el proyecto con README y gitignore

Verifica que .env nunca aparece en git status: es la prueba de que tu .gitignore funciona y de que tu secreto está protegido.

Puntos a recordar

1. Tres zonas: directorio de trabajo → staging (git add) → repositorio local (git commit).
2. git init crea el repositorio (carpeta .git/).
3. Un commit es una instantánea + un mensaje, unido al commit padre.
4. Buenos mensajes: imperativo, claros, atómicos, que expliquen el porqué.
5. .gitignore protege los secretos y excluye los archivos inútiles.

A continuación

Lección 07 — Ramas e historial: trabajar en varias versiones en paralelo sin romper la versión principal.