Guía básica de GIT
Conceptos Básicos de Git
¿Qué es Git?
Git es un sistema de control de versiones distribuido que permite rastrear cambios en archivos a lo largo del tiempo. Fue creado por Linus Torvalds en 2005 y se ha convertido en el estándar de la industria para el control de versiones.
¿Cómo Funciona Git?
Git funciona mediante snapshots (instantáneas) de tu proyecto. Cada vez que haces un commit, Git toma una foto del estado de todos tus archivos en ese momento y almacena una referencia a esa instantánea. Si un archivo no ha cambiado, Git solo guarda un enlace al archivo anterior idéntico.
Conceptos Fundamentales
1. Repositorio (Repository)
Un repositorio es un directorio que contiene tu proyecto y todo el historial de versiones. Puede ser:
- Local: En tu máquina
- Remoto: En un servidor (GitHub, GitLab, Bitbucket, etc.)
2. Commit
Un commit es una instantánea de tu proyecto en un momento específico. Cada commit tiene:
- Un hash único (SHA-1) que lo identifica
- Un mensaje que describe los cambios
- Un autor y fecha
- Referencias a commits anteriores (padres)
3. Branch (Rama)
Una rama es una línea de desarrollo independiente. Te permite trabajar en diferentes características sin afectar la rama principal. La rama por defecto generalmente se llama main o master.
4. Working Directory (Directorio de Trabajo)
Es donde estás trabajando actualmente. Contiene los archivos que puedes ver y editar.
5. Staging Area (Área de Preparación)
También conocida como "index", es un área intermedia donde preparas los cambios antes de hacer commit. Los archivos pasan de "untracked" o "modified" a "staged".
6. HEAD
HEAD es un puntero que apunta al commit actual en la rama en la que estás trabajando.
Estados de los Archivos en Git
- Untracked (Sin seguimiento): Archivos nuevos que Git no está rastreando
- Modified (Modificado): Archivos que han sido cambiados pero no están en staging
- Staged (En preparación): Archivos modificados que están listos para commit
- Committed (Confirmado): Cambios guardados en el repositorio local
Flujo de Trabajo Básico
Lo Más Importante de Git
- Distribuido: Cada desarrollador tiene una copia completa del historial
- Ramas: Permiten trabajo paralelo sin conflictos
- Commits Atómicos: Cada commit representa un cambio lógico completo
- Historial Completo: Git guarda todo el historial, permitiendo revertir cambios
- Integridad: Usa checksums SHA-1 para garantizar la integridad de los datos
Diferencias entre Git Merge y Git Rebase
Git Merge
¿Qué hace? git merge combina los cambios de una rama en otra, creando un commit de merge que tiene dos padres. Preserva el historial completo de ambas ramas.
Cuándo usarlo:
- Cuando trabajas en una rama compartida (como
mainodevelop) - Cuando quieres preservar el historial exacto de cómo se desarrolló el proyecto
- En proyectos donde el historial es importante para auditoría
Ventajas:
- ✅ Preserva el historial completo
- ✅ No reescribe commits existentes
- ✅ Seguro para ramas compartidas
- ✅ Muestra claramente cuándo se integraron las ramas
Desventajas:
- ❌ Puede crear un historial más complejo con muchos commits de merge
- ❌ El historial puede volverse difícil de seguir
Ejemplo:
Resultado visual:
Git Rebase
¿Qué hace? git rebase toma los commits de tu rama y los "re-aplica" sobre otra rama, creando un historial lineal. Reescribe el historial de commits.
Cuándo usarlo:
- Cuando trabajas en una rama local que no ha sido compartida
- Cuando quieres mantener un historial limpio y lineal
- Antes de hacer merge a la rama principal
Ventajas:
- ✅ Historial lineal y limpio
- ✅ Más fácil de leer y seguir
- ✅ Evita commits de merge innecesarios
Desventajas:
- ❌ Reescribe el historial (cambia los hashes de los commits)
- ❌ NUNCA debe usarse en ramas compartidas/publicadas
- ❌ Puede ser más complejo resolver conflictos
Ejemplo:
Resultado visual:
Comparación Visual
Antes del merge/rebase:
Después de merge:
Después de rebase:
¿Cuándo Usar Cada Uno?
| Situación | Usar |
|---|---|
| Rama compartida/publicada | Merge |
| Rama local personal | Rebase |
| Quieres historial completo | Merge |
| Quieres historial limpio | Rebase |
| Trabajo en equipo | Merge |
| Trabajo individual | Rebase |
Rebase Interactivo
Puedes usar git rebase -i para editar, combinar o eliminar commits antes de aplicarlos:
Cómo Hacer un Pull Request (PR)
Un Pull Request (PR) es una solicitud para integrar cambios de una rama a otra. Es el mecanismo estándar para revisar código antes de integrarlo.
Proceso Paso a Paso
1. Preparar tu Entorno Local
2. Crear una Nueva Rama
Convenciones de nombres:
feature/nombre: Para nuevas característicasfix/nombre: Para correcciones de bugshotfix/nombre: Para correcciones urgentesrefactor/nombre: Para refactorizaciones
3. Hacer tus Cambios
Edita los archivos necesarios en tu editor de código.
4. Revisar tus Cambios
5. Agregar Archivos al Staging
6. Hacer Commit
Convenciones de mensajes de commit:
feat:Nueva característicafix:Corrección de bugdocs:Cambios en documentaciónstyle:Cambios de formato (no afectan código)refactor:Refactorización de códigotest:Agregar o modificar testschore:Tareas de mantenimiento
7. Sincronizar con la Rama Principal (Opcional pero Recomendado)
Antes de hacer push, es buena práctica actualizar tu rama con los últimos cambios de main:
8. Hacer Push de tu Rama
9. Crear el Pull Request en GitHub/GitLab
En GitHub:
- Ve al repositorio en GitHub
- Verás un banner que dice "Compare & pull request"
- Haz clic y completa:
- Título: Descripción breve y clara
- Descripción: Explica qué cambios hiciste y por qué
- Reviewers: Selecciona quién debe revisar
- Labels: Agrega etiquetas relevantes
- Haz clic en "Create pull request"
En GitLab:
- Ve al repositorio en GitLab
- Haz clic en "Merge requests" → "New merge request"
- Selecciona tu rama fuente y la rama destino
- Completa el título y descripción
- Haz clic en "Create merge request"
10. Responder a Comentarios y Hacer Cambios
Si hay comentarios o solicitudes de cambios:
11. Después de que se Apruebe el PR
Una vez aprobado y mergeado:
Mejores Prácticas para PRs
- Mantén PRs pequeños: Es más fácil revisar cambios pequeños
- Un PR = Una característica: No mezcles múltiples features
- Describe claramente: Explica el qué, por qué y cómo
- Incluye tests: Si es aplicable, agrega o actualiza tests
- Actualiza documentación: Si cambias funcionalidad, actualiza docs
- Revisa tu propio código: Antes de pedir review, revísalo tú primero
Cheatsheet de Comandos Git
Configuración Inicial
Comandos Básicos
git init
Inicializa un nuevo repositorio Git en el directorio actual.
git clone
Clona un repositorio remoto a tu máquina local.
git status
Muestra el estado de tu working directory y staging area.
git add
Agrega archivos al staging area.
git commit
Guarda los cambios del staging area en el repositorio.
git log
Muestra el historial de commits.
git diff
Muestra las diferencias entre versiones.
Trabajo con Ramas
git branch
Gestiona ramas.
git checkout
Cambia de rama o restaura archivos.
git switch (Git 2.23+)
Comando moderno para cambiar de rama (más intuitivo que checkout).
Merge y Rebase
git merge
Combina ramas.
git rebase
Re-aplica commits sobre otra rama.
Trabajo con Remotos
git remote
Gestiona repositorios remotos.
git fetch
Descarga cambios del remoto sin mergear.
git pull
Descarga y mergea cambios del remoto.
git push
Sube cambios al repositorio remoto.
Deshacer Cambios
Stash (Guardar Cambios Temporalmente)
Tags
Búsqueda y Filtrado
Limpieza
Diagrama Visual de Git
Arquitectura General de Git
Flujo de Estados de Archivos
Estructura de Commits y Ramas
Comparación: Merge vs Rebase
ANTES (Estado Inicial):
DESPUÉS DE MERGE:
DESPUÉS DE REBASE:
Flujo Completo de Trabajo con Git
Áreas de Git (Three-Tree Architecture)
HEAD y Referencias
Resumen de Mejores Prácticas
✅ Hacer
- Haz commits pequeños y frecuentes
- Escribe mensajes de commit claros y descriptivos
- Mantén ramas actualizadas con la rama principal
- Usa
git pull --rebasepara mantener historial limpio - Revisa tus cambios con
git diffantes de commitear - Haz push regularmente de tu trabajo
- Usa ramas para features nuevas
- Elimina ramas después de mergearlas
❌ No Hacer
- No hagas commit de archivos de configuración local
- No hagas
git push --forcea ramas compartidas - No hagas
git rebaseen ramas compartidas/publicadas - No hagas commits de archivos binarios grandes
- No ignores el
.gitignore - No hagas commits con mensajes vagos como "fix" o "update"
- No mezcles múltiples features en un solo commit
- No hagas push directamente a
mainomaster
Recursos Adicionales
- Documentación oficial: https://git-scm.com/doc
- Git Book: https://git-scm.com/book
- GitHub Guides: https://guides.github.com
- Visual Git Reference: https://marklodato.github.io/visual-git-guide/