Fundamentos de Git para control de versiones en proyectos

Modelo mental de Git: tres “lugares” donde viven tus cambios

Para usar Git con seguridad, conviene pensar en tres zonas:

• Directorio de trabajo (working directory): es tu carpeta del proyecto tal como la ves en el explorador. Aquí editas archivos con tu editor.
• Área de preparación (staging area / index): es una “lista de cambios” que estás preparando para el próximo commit. No es automático: tú decides qué entra.
• Repositorio (repository): es el historial guardado por Git (commits). Aquí quedan registrados los cambios confirmados.

Flujo típico: editas en el directorio de trabajo → seleccionas cambios con git add (pasan a staging) → confirmas con un commit (pasan al repositorio). En este capítulo practicaremos especialmente add, status y diff para entender qué está pasando en cada zona.

Crear o inicializar un repositorio

Opción A: iniciar Git en una carpeta existente

Entra a la carpeta del proyecto y ejecuta:

cd ruta/a/mi-proyecto
git init

Qué esperar en la terminal: Git crea una carpeta oculta .git/ (no la borres). Ahí vive el repositorio (historial, configuración, referencias).

Opción B: crear carpeta y luego iniciar

mkdir mi-proyecto
cd mi-proyecto
git init

Verificar que estás dentro de un repo

git status

Si todo va bien, verás un mensaje indicando la rama actual (por ejemplo On branch main) y el estado del directorio de trabajo.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Inspeccionar el estado: cómo leer git status

git status es tu “panel de control”. Te dice qué cambió y en qué zona está cada cambio.

Salida típica 1: repo recién creado

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

• No commits yet: aún no hay historial.
• nothing to commit: no hay cambios preparados.

Salida típica 2: archivos sin seguimiento (untracked)

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md
	notes.txt

nothing added to commit but untracked files present (use "git add" to track)

• Untracked: Git ve los archivos, pero todavía no los versiona.
• La pista “use git add…” te dice cómo pasarlos a staging.

Salida típica 3: cambios no preparados (modified, not staged)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

• Changes not staged: modificaste algo en el directorio de trabajo, pero aún no lo seleccionaste para el próximo commit.

Salida típica 4: cambios preparados (staged)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   src/app.txt

• Changes to be committed: esto ya está en staging y entraría en el próximo commit.

Ver diferencias: git diff para entender qué cambió

La familia diff te ayuda a comparar zonas:

• git diff: compara directorio de trabajo vs staging (lo que cambiaste pero aún no preparaste).
• git diff --staged: compara staging vs repositorio (lo que ya preparaste para el próximo commit).

Cómo leer un diff (lo esencial)

diff --git a/README.md b/README.md
index e69de29..b3f1a2c 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1,2 @@
+Mi proyecto
+Notas iniciales

• Las líneas con + se agregaron.
• Las líneas con - se eliminaron.
• Los bloques @@ indican el rango de líneas afectadas.

Convenciones para organizar un proyecto versionado

Git funciona mejor cuando el proyecto tiene una estructura clara y archivos “clave” que ayudan a colaborar.

Estructura mínima recomendada (genérica)

mi-proyecto/
  README.md
  .gitignore
  src/
  docs/
  data/
  scripts/

• README.md: qué es el proyecto, cómo ejecutarlo, ejemplos de uso.
• .gitignore: lista de archivos/carpetas que no deben versionarse (por ejemplo, temporales, builds, credenciales).
• src/: código fuente.
• docs/: documentación adicional (guías, diagramas).
• data/: datos de ejemplo (evita datos sensibles o enormes).
• scripts/: automatizaciones (por ejemplo, tareas repetitivas).

Qué NO suele versionarse (regla práctica)

• Archivos generados automáticamente (builds, binarios, caches).
• Dependencias descargadas (según el ecosistema).
• Secretos: claves, tokens, contraseñas.
• Archivos enormes que cambian constantemente (si no es imprescindible).

Ejemplo de .gitignore simple

# Temporales
*.log
.DS_Store

# Editor
.vscode/

# Salidas generadas
/dist/
/build/

Adáptalo a tu lenguaje/herramientas. La idea es mantener el historial limpio y útil.

Configuración básica de Git: identidad, editor y opciones útiles

Antes de trabajar, configura tu identidad. Esto se guarda en tus commits.

Identidad (nombre y correo)

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

Para verificar:

git config --global --list

Elegir editor para mensajes y operaciones

Git abre un editor en ciertas acciones (por ejemplo, al escribir mensajes largos). Puedes definirlo:

# Ejemplo con VS Code
git config --global core.editor "code --wait"

Otros ejemplos comunes (elige uno):

# Nano
git config --global core.editor "nano"

# Vim
git config --global core.editor "vim"

Opciones prácticas recomendadas

• Colores en la salida (si no vienen por defecto):

git config --global color.ui auto

• Renombrar la rama inicial a main (si tu Git aún usa otro nombre):

git config --global init.defaultBranch main

• Final de línea consistente (especialmente si trabajas entre Windows/macOS/Linux):

# Windows (recomendación común)
git config --global core.autocrlf true

# macOS/Linux (recomendación común)
git config --global core.autocrlf input

Estas opciones reducen fricción al colaborar y hacen más predecible el comportamiento.

Ejercicio guiado: mini proyecto para practicar add, status y diff

Objetivo: ver claramente cómo se mueven los cambios entre directorio de trabajo y staging, y cómo inspeccionarlos.

Paso 1: crear el proyecto y archivos base

mkdir practica-git
cd practica-git
git init

Crea esta estructura:

mkdir src docs

Crea un README.md con este contenido:

# Practica Git

Proyecto pequeño para aprender status/add/diff.

Crea un archivo de código simple src/app.txt:

version: 1
mensaje: hola

Ahora inspecciona:

git status

Deberías ver ambos archivos como Untracked.

Paso 2: preparar solo un archivo (staging selectivo)

Prepara únicamente el README:

git add README.md

Vuelve a revisar:

git status

Qué deberías observar:

• README.md aparece en Changes to be committed (staged).
• src/app.txt sigue en Untracked files.

Paso 3: modificar un archivo ya staged y ver el efecto

Edita README.md y agrega una línea al final:

Incluye ejercicios paso a paso.

Ahora ejecuta:

git status

Es común ver el mismo archivo en dos secciones: una parte staged (la versión que preparaste) y otra parte modificada (cambios nuevos en el directorio de trabajo).

Inspecciona diferencias:

• Qué cambió en el directorio de trabajo respecto a staging:

git diff

• Qué está actualmente en staging (lo que se preparó antes de la última edición):

git diff --staged

Paso 4: preparar el resto y comparar

Ahora prepara también el archivo de src:

git add src/app.txt

Y prepara la nueva modificación del README:

git add README.md

Revisa el estado:

git status

En este punto, lo habitual es que no haya cambios “not staged” si preparaste todo. Comprueba:

git diff

Si no hay salida, significa que el directorio de trabajo y staging están alineados. Aun así, puedes ver lo que está en staging:

git diff --staged

Paso 5: practicar staging parcial (opcional, muy útil)

Haz dos cambios en src/app.txt, por ejemplo:

version: 2
mensaje: hola
extra: linea nueva

Ejecuta:

git diff

Ahora usa el modo interactivo para preparar solo parte (si tu terminal lo soporta cómodamente):

git add -p src/app.txt

Git te irá mostrando “hunks” (bloques de cambios) y podrás elegir qué preparar. Luego revisa:

git status
git diff
git diff --staged

La meta es que puedas explicar con tus palabras qué cambios están en cada zona y por qué diff cambia según el flag.

Guía rápida de comandos usados (chuleta práctica)