Domina las operaciones basicas de Git | Tutoriales

Lo que aprenderas en este tutorial

Inicializacion de un repositorio Git (init)
Staging de cambios (add)
Creacion de commits (commit)
Push a remoto (push)

Requisitos previos: Git debe estar instalado. Si git --version muestra la version, estas listo.

Que es Git y por que fue creado

El origen de Git

Git fue desarrollado en 2005 por Linus Torvalds (el creador del kernel de Linux).

En aquel entonces, el desarrollo del kernel de Linux utilizaba un sistema de control de versiones comercial llamado “BitKeeper”. Sin embargo, debido a problemas de licencia, BitKeeper dejo de estar disponible, y Linus creo un nuevo sistema de control de versiones en solo 2 semanas. Ese fue Git.

“El nombre Git es una jerga britanica que significa ‘persona desagradable’. Linus tiende a poner nombres autoironicos a sus proyectos”

Problemas que Git resolvio

Control de versiones distribuido: Sin depender de un servidor central, cada desarrollador tiene el historial completo
Operaciones rapidas: La mayoria de las operaciones se completan localmente, haciendolas muy rapidas
Ramas ligeras: Crear y cambiar ramas es instantaneo
Integridad de datos: Todos los cambios estan protegidos criptograficamente mediante hash SHA-1

Git en la actualidad

Actualmente, Git es el sistema de control de versiones mas utilizado en el mundo. Segun la encuesta de Stack Overflow de 2022, mas del 93% de los desarrolladores usan Git.

Entender la estructura interna de Git

Para usar Git efectivamente, es importante entender su funcionamiento interno.

Las 3 areas

Git tiene 3 areas principales:

flowchart LR
    WD["Directorio de trabajo<br/>(Working Dir)"] -->|git add| SA["Area de staging<br/>(Staging Area)"]
    SA -->|git commit| Repo["Repositorio<br/>(.git)"]

Directorio de trabajo (Working Directory): Donde editas los archivos realmente
Area de staging (Staging Area / Index): Donde preparas los cambios para el proximo commit
Repositorio (.git): Donde se guarda el historial de commits

Modelo de objetos de Git

Git gestiona los datos con 4 tipos de objetos:

blob: Contenido de archivos
tree: Estructura de directorios
commit: Snapshot + metadatos
tag: Referencia a un commit especifico

Todos los objetos se identifican por un hash SHA-1 (40 caracteres hexadecimales).

Step 1: Inicializacion del repositorio

Primero, crea un directorio para el proyecto e inicializalo como repositorio Git.

# Crear directorio del proyecto
mkdir my-first-repo
cd my-first-repo

# Inicializar como repositorio Git
git init

Al ejecutar git init, se crea una carpeta oculta .git. Este es el lugar donde Git almacena la informacion de gestion.

Contenido del directorio .git

$ ls -la .git/
├── HEAD          # Referencia a la rama actual
├── config        # Configuracion especifica del repositorio
├── hooks/        # Scripts de Git hooks
├── objects/      # Todos los objetos Git
└── refs/         # Referencias a ramas y tags

Documentacion oficial: git-init

Step 2: Creacion y staging de archivos

Crea un nuevo archivo y agregalo al control de Git.

# Crear archivo README
echo "# My First Repository" > README.md

# Verificar estado
git status

# Agregar archivo al staging
git add README.md

# Verificar estado nuevamente
git status

git add agrega los cambios al area de staging. Esta es la operacion de seleccionar “los cambios a incluir en el proximo commit”.

Por que es necesaria el area de staging

“El area de staging es un buffer para organizar los commits en unidades logicas. No es necesario hacer commit de todo a la vez” - Pro Git Book

Gracias al area de staging:

Commits parciales: Puedes seleccionar solo algunos cambios de varios para hacer commit
Revision: Puedes confirmar que incluir antes del commit
Commits atomicos: Puedes agrupar solo los cambios relacionados

Patrones comunes de add

# Agregar archivo especifico
git add filename.txt

# Agregar todos los cambios
git add .

# Agregar por extension
git add *.js

# Agregar interactivamente (seleccionar cambios parciales)
git add -p

Documentacion oficial: git-add

Step 3: Creacion del commit

Registra los cambios en staging como un commit.

# Crear commit
git commit -m "Initial commit: Add README"

# Ver historial de commits
git log

Como escribir buenos mensajes de commit

La convencion Conventional Commits es ampliamente adoptada:

<type>(<scope>): <subject>

<body>

<footer>

Ejemplos de type:

feat: Nueva funcionalidad
fix: Correccion de bug
docs: Documentacion
style: Cambios de formato
refactor: Refactorizacion
test: Agregar/modificar tests
chore: Configuracion de build, etc.

Ejemplos de buenos mensajes de commit:

# Buenos ejemplos
git commit -m "feat: Add user authentication"
git commit -m "fix: Resolve login button not working on mobile"
git commit -m "docs: Update API documentation"

# Malos ejemplos
git commit -m "fix"
git commit -m "Update"
git commit -m "cambios"

Mejores practicas: Escribe en formato “Al aplicar este commit, se hara X”. Usa el modo imperativo y tiempo presente.

Documentacion oficial: git-commit

Step 4: Push al repositorio remoto

Crea un repositorio remoto en GitHub u otro servicio y haz push de los cambios locales.

# Agregar repositorio remoto
git remote add origin https://github.com/username/my-first-repo.git

# Push de la rama principal
git push -u origin main

La opcion -u configura la rama upstream para que puedas hacer push solo con git push la proxima vez.

Verificar remotos

# Verificar remotos configurados
git remote -v

# Ejemplo de salida:
# origin  https://github.com/username/my-first-repo.git (fetch)
# origin  https://github.com/username/my-first-repo.git (push)

Documentacion oficial: git-push

Resumen del flujo de trabajo basico

# Flujo de trabajo diario
git status              # Verificar estado actual
git add .               # Agregar cambios al staging
git commit -m "message" # Crear commit
git push                # Push a remoto

Visualizacion de operaciones Git

flowchart LR
    subgraph WD["Working Directory"]
    end
    subgraph SA["Staging Area"]
    end
    subgraph Repo["Repository"]
    end
    WD -->|git add| SA
    SA -->|git commit| Repo
    Repo -->|git checkout| WD
    Repo -->|git reset --soft| SA

Errores comunes y antipatrones

1. Commits gigantes

# Mal ejemplo: Hacer commit de todo a la vez
git add .
git commit -m "Add all features"

# Buen ejemplo: Dividir en unidades logicas
git add src/auth/
git commit -m "feat: Add authentication module"

git add src/api/
git commit -m "feat: Add API endpoints"

2. Hacer commit de informacion sensible

# Archivos que deberias agregar a .gitignore
.env
*.pem
config/secrets.yml
node_modules/

3. Omitir mensajes de commit

Los mensajes de commit son documentacion para tu futuro yo y otros desarrolladores. Escribe mensajes significativos.

Problemas comunes y soluciones

Cometiste un error en el mensaje de commit

# Modificar el mensaje del ultimo commit
git commit --amend -m "nuevo mensaje"

Atencion: Evita modificar commits que ya hayas pusheado. Reescribir el historial afecta a otros desarrolladores.

Quieres deshacer add

# Deshacer staging (mantiene los cambios en archivos)
git reset HEAD filename.txt

# Nuevo comando desde Git 2.23
git restore --staged filename.txt

Quieres deshacer el ultimo commit

# Deshacer commit, dejar cambios en staging
git reset --soft HEAD~1

# Deshacer commit, dejar cambios en directorio de trabajo
git reset HEAD~1

# Eliminar commit y cambios completamente (peligroso)
git reset --hard HEAD~1

Quieres restaurar un archivo a un estado anterior

# Restaurar archivo desde un commit especifico
git checkout <commit-hash> -- filename.txt

# Desde Git 2.23
git restore --source=<commit-hash> filename.txt

Mejores practicas de configuracion

Si es la primera vez que usas Git, realiza la siguiente configuracion:

# Configurar nombre de usuario y email (obligatorio)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# Establecer nombre de rama por defecto a main
git config --global init.defaultBranch main

# Conversion automatica de saltos de linea (macOS/Linux)
git config --global core.autocrlf input

# Configurar editor
git config --global core.editor "code --wait"

# Habilitar salida con colores
git config --global color.ui auto

Siguientes pasos

Una vez que domines las operaciones basicas, aprende a usar ramas. Es una habilidad esencial para el desarrollo en equipo.

Recursos para continuar aprendiendo:

Aprender estrategias de ramas -> Practica de estrategias de ramas Git
Aprender interactivamente -> Learn Git Branching

Enlaces de referencia

Documentacion oficial

Documentacion oficial de Git - Referencia oficial
Pro Git Book (Espanol) - Libro completo de Git gratuito

Articulos y tutoriales recomendados

Conventional Commits - Convencion de mensajes de commit
GitHub Git Cheat Sheet - Lista de comandos frecuentes
Tutorial de Git de Atlassian - Aprende Git visualmente

Herramientas

GitHub Desktop - Operar Git con GUI
GitLens (Extension VS Code) - Visualizar historial Git en VS Code
Learn Git Branching - Sitio interactivo para aprender Git

← Volver a la lista