Tabla de contenido

Introducción: Por qué Git es Esencial para Todo Desarrollador

Imagina este escenario: llevas tres semanas desarrollando una nueva funcionalidad para tu aplicación. Funciona perfectamente en tu máquina. Pero cuando intentas integrarla con el código de tu compañero, todo se rompe. No recuerdas qué cambiaste, no puedes volver atrás, y el código del otro también se vio afectado.

Sin Git, este escenario es un desastre total. Con Git, es un martes normal.

Git es un sistema de control de versiones distribuido. Esto significa que:

  1. Guarda snapshots de tu proyecto cada vez que lo decides (commits)
  2. Puedes volver a cualquier punto del historial en segundos
  3. Múltiples personas pueden trabajar simultáneamente sin pisarse
  4. Funciona sin internet — todo el historial vive en tu computadora
  5. Permite experimentar con ramas (branches) sin afectar el código estable

Git fue creado por Linus Torvalds en 2005 (el mismo creador del kernel de Linux) y hoy es utilizado por el 94% de los desarrolladores del mundo. No importa si trabajas con PHP, JavaScript, Python, Rust o cualquier otro lenguaje — Git es la herramienta que todos usan.

Si quieres una introducción rápida, revisa nuestro artículo sobre ¿Qué es Git y por qué aprenderlo?.

Parte 1: Fundamentos de Git

1.1 ¿Qué es Git?

Git no guarda “diferencias” entre archivos como otros sistemas de control de versiones. En cambio, guarda snapshots (fotos completas) del estado de tu proyecto en cada commit.

Cuando haces commit, Git:

  1. Toma una foto de todos los archivos en su estado actual
  2. Guarda esa foto con un identificador único (SHA-1)
  3. Registra quién hizo el cambio, cuándo y por qué (el mensaje)

Los archivos que no cambiaron entre commits no se duplican — Git simplemente crea un enlace al archivo ya guardado. Esto hace que Git sea sorprendentemente eficiente en espacio.

1.2 Instalación y configuración

Mac (Homebrew):

brew install git

Windows: Descarga desde git-scm.com/download/win

Linux (Ubuntu/Debian):

sudo apt update && sudo apt install git

Verificar instalación:

git --version
# git version 2.45.0

Configuración inicial obligatoria:

# Tu nombre (aparecerá en cada commit)
git config --global user.name "Tu Nombre"

# Tu correo (usa el mismo de GitHub)
git config --global user.email "tu@correo.com"

# Editor por defecto (opcional)
git config --global core.editor "code --wait"

# Nombre de la rama principal
git config --global init.defaultBranch main

# Colores en la terminal
git config --global color.ui auto

Verificar configuración:

git config --list

Para una guía paso a paso de instalación, revisa Cómo instalar y configurar Git.

1.3 El flujo de trabajo básico

Git maneja tres áreas de trabajo:

Directorio de trabajo → Staging Area → Repositorio (commits)
     (tus archivos)      (git add)        (git commit)
  1. Directorio de trabajo: Donde editas tus archivos
  2. Staging area: Donde preparas los cambios para el próximo commit
  3. Repositorio: Donde se guardan los commits permanentemente

Ejemplo completo:

# 1. Crear un proyecto nuevo
mkdir mi-proyecto
cd mi-proyecto
git init

# 2. Crear archivos
echo "# Mi Proyecto" > README.md
echo "<?php echo 'Hola mundo'; ?>" > index.php

# 3. Ver el estado
git status
# On branch main
# Untracked files:
#   README.md
#   index.php

# 4. Agregar archivos al staging area
git add README.md    # Un archivo específico
git add index.php    # Otro archivo
# O para agregar todo:
# git add .

# 5. Crear el commit
git commit -m "feat: agrega archivos iniciales del proyecto"

# 6. Verificar
git status
# On branch main
# nothing to commit, working tree clean

Convención de mensajes de commit:

feat:     Nueva funcionalidad
fix:      Corrección de error
docs:     Cambios en documentación
style:    Formato (sin cambios funcionales)
refactor: Reestructura de código (sin)
test:     Agregar o modificar tests
chore:    Tareas de mantenimiento

1.4 El historial de commits

# Ver historial completo
git log

# Historial compacto (una línea por commit)
git log --oneline
# abc1234 feat: agrega archivos iniciales
# def5678 fix: corrige error de conexión
# ghi9012 docs: agrega README

# Historial con gráfico de ramas
git log --oneline --graph --all

# Ver los cambios de un commit específico
git show abc1234

# Ver quién hizo más commits
git shortlog -sn

Para más sobre el historial, revisa 4 cosas sobre los Fork en GitHub y 9 buenas prácticas al crear pull request.

Parte 2: Ramas y Fusión

2.1 ¿Qué son las ramas?

Una rama es una línea de desarrollo independiente. Piensa en las ramas como universos paralelos de tu proyecto:

  • La rama main es tu código estable y probado
  • La rama feature/login es donde desarrollas el sistema de login
  • La rama fix/header-bug es donde corriges un bug del header

Cada rama es completamente independiente. Puedes romper todo en feature/login sin afectar main en absoluto.

2.2 Crear y cambiar de rama

# Ver ramas existentes
git branch
# * main

# Crear una nueva rama
git branch feature/nueva-funcionalidad

# Cambiar a esa rama
git checkout feature/nueva-funcionalidad

# O crear y cambiar en un solo comando (recomendado)
git checkout -b feature/nueva-funcionalidad

# Trabajar, hacer commits...
git add .
git commit -m "feat: agrega componente de navegación"

# Volver a main
git checkout main

# Ver que main no tiene los cambios de la otra rama
git log --oneline
# Solo muestra commits de main

2.3 Merge: Fusionar ramas

# Asegúrate de estar en la rama destino
git checkout main

# Fusionar la rama de feature
git merge feature/nueva-funcionalidad

Tipos de merge:

# Fast-forward (main no tiene nuevos commits desde que se creó la rama)
# Git simplemente mueve el puntero de main al último commit de la rama

# Three-way merge (main tiene commits propios)
# Git crea un "merge commit" que une ambas líneas de desarrollo

# Merge con --no-ff (forzar merge commit siempre)
git merge --no-ff feature/nueva-funcionalidad

2.4 Resolver conflictos

Los conflictos ocurren cuando dos ramas modifican las mismas líneas del mismo archivo:

git merge feature/otra-rama
# Auto-merging index.php
# CONFLICT (content): Merge conflict in index.php
# Automatic merge failed; fix conflicts and then commit the result.

Para resolver:

  1. Abre el archivo conflictivo en tu editor
  2. Busca los marcadores de conflicto:
<<<<<<< HEAD
// Tu código en main
$version = "2.0";
=======
// El código de la otra rama
$version = "3.0-beta";
>>>>>>> feature/otra-rama
  1. Elige qué código mantener (o combínalos)
  2. Elimina los marcadores (<<<<<<<, =======, >>>>>>>)
  3. Haz commit del merge:
git add index.php
git commit -m "merge: resuelve conflicto en versión"

2.5 Rebase: Historial limpio

Mientras merge preserva el historial exacto, rebase reescribe el historial para que sea lineal:

# Estás en feature/login
# main ha avanzado desde que creaste la rama

# En lugar de merge, usa rebase
git checkout feature/login
git rebase main

# Ahora feature/login está "encima" de los últimos commits de main
# El historial es limpio y lineal

# Luego haces merge (será fast-forward)
git checkout main
git merge feature/login

Regla de oro: Nunca hagas rebase de ramas públicas (que otros usan). Solo rebase de tus ramas privadas antes de hacer merge.

Para un flujo de ramas profesional, revisa Git Flow: flujo de trabajo con ramas.

Parte 3: Git Remoto y GitHub

3.1 Conectar con GitHub

# 1. Crea un repositorio en github.com (sin inicializar con README)

# 2. Conecta tu repo local con el remoto
git remote add origin https://github.com/tuusuario/mi-proyecto.git

# 3. Verifica la conexión
git remote -v
# origin  https://github.com/tuusuario/mi-proyecto.git (fetch)
# origin  https://github.com/tuusuario/mi-proyecto.git (push)

# 4. Renombra la rama local a main (si es necesario)
git branch -M main

# 5. Sube tu código
git push -u origin main

3.2 Push, Pull y Fetch

# push: enviar commits locales al repositorio remoto
git push

# pull: bajar cambios remotos e integrarlos localmente
git pull

# fetch: bajar cambios sin integrarlos (solo descarga)
git fetch

# Ver diferencias con el remoto
git diff main origin/main

# Ver ramas remotas
git branch -r

3.3 Clonar un repositorio

# Clonar un repositorio existente
git clone https://github.com/tuusuario/mi-proyecto.git

# Clonar en una carpeta específica
git clone https://github.com/tuusuario/mi-proyecto.git mi-carpeta

# El clone descarga TODO el historial, todas las ramas y configura el remoto

Para aprender GitHub desde cero, revisa GitHub Desde Cero y Cómo subir una página a GitHub Pages.

Parte 4: Colaboración en GitHub

4.1 Fork y clone

Un fork es una copia personal de un repositorio de otra persona:

  1. Ve al repositorio en GitHub
  2. Haz clic en Fork (esquina superior derecha)
  3. Se crea una copia bajo tu cuenta: github.com/tuusuario/repo-original
  4. Clona tu fork: git clone https://github.com/tuusuario/repo-original.git

4.2 Pull Requests

Un Pull Request (PR) es una solicitud para fusionar tus cambios con el proyecto original:

  1. Crea una rama en tu fork
  2. Haz tus cambios y commits
  3. Sube la rama: git push origin mi-feature
  4. En GitHub, ve al repositorio original
  5. Haz clic en “Compare & pull request”
  6. Describe qué cambiaste y por qué
  7. Envía el PR

Buenas prácticas para PRs:

  • Título descriptivo: “feat: agregar sistema de autenticación con JWT”
  • Descripción clara: qué hace, por qué, cómo probarlo
  • Screenshots si hay cambios visuales
  • Commits atómicos (cada commit hace una cosa)
  • Revisar tu propio código antes de enviarlo

Para buenas prácticas de PR, revisa 9 buenas prácticas al crear pull request.

4.3 Code Review

El code review es cuando otro desarrollador revisa tus cambios antes de fusionarlos:

  • Deja comentarios específicos en líneas de código
  • Sugiere mejoras sin ser destructivo
  • Aprueba cuando el código está listo
  • Pide cambios si hay problemas

Como autor del PR:

  • Responde a todos los comentarios
  • Haz los cambios solicitados y haz push
  • Agradece la revisión

4.4 Issues y proyectos

Issues son tickets para reportar bugs, solicitar features o documentar tareas:

## Descripción
El botón de login no redirige después de autenticar

## Pasos para reproducir
1. Ir a /login
2. Ingresar credenciales válidas
3. Clic en "Iniciar sesión"

## Resultado esperado
Redirigir a /dashboard

## Resultado actual
Se queda en la misma página

## Environment
- Navegador: Chrome 120
- SO: macOS 14

GitHub Projects organiza issues en tableros Kanban:

  • To Do → In Progress → Done

Parte 5: Git Avanzado

5.1 Stash: Guardar trabajo temporal

Cuando necesitas cambiar de rama pero no quieres hacer commit de trabajo a medio terminar:

# Guardar cambios actuales
git stash save "WIP: trabajando en el login"

# Ver stashes guardados
git stash list
# stash@{0}: On main: WIP: trabajando en el login

# Cambiar de rama, hacer lo que necesites...
git checkout main
git checkout -b hotfix/urgente

# Volver y recuperar el stash
git checkout feature/login
git stash pop

5.2 Cherry-pick: Seleccionar commits específicos

Aplicar un commit específico de otra rama sin hacer merge completo:

# Ver el hash del commit que quieres
git log --oneline feature/login
# abc1234 feat: agregar validación de email

# Aplicar solo ese commit a tu rama actual
git cherry-pick abc1234

5.3 Reset y Revert

# Reset: deshacer commits (cambia el historial)
git reset --soft HEAD~1    # Deshace el último commit, mantiene cambios en staging
git reset --mixed HEAD~1   # Default: deshace commit, mantiene cambios sin staging
git reset --hard HEAD~1    # Deshace TODO: commit + cambios (peligroso)

# Revert: deshacer un commit creando uno nuevo (seguro para ramas públicas)
git revert abc1234
# Crea un nuevo commit que invierte los cambios de abc1234

Regla: Usa reset en ramas privadas y revert en ramas públicas.

5.4 .gitignore

El archivo .gitignore le dice a Git qué archivos no rastrear:

# Dependencias
node_modules/
vendor/

# Variables de entorno
.env
.env.local

# Build output
dist/
build/
*.min.js

# IDE
.vscode/
.idea/
*.swp

# OS
.DS_Store
Thumbs.db

# Logs
*.log

Para entender cómo funciona, revisa ¿Cómo funciona un .gitignore?.

5.5 Git log avanzado

# Ver quién cambió cada línea de un archivo
git blame index.php

# Buscar un texto en el historial
git log -S "password_hash"

# Ver cambios en un rango de fechas
git log --after="2026-01-01" --before="2026-04-01"

# Ver cambios de un autor específico
git log --author="Abraham"

# Ver cambios de un archivo específico
git log --oneline -- src/components/Header.php

Parte 6: GitHub Actions (CI/CD)

GitHub Actions automatiza tareas cada vez que haces push o creas un PR.

Ejemplo: Ejecutar tests automáticamente

# .github/workflows/tests.yml
name: Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'

      - name: Install dependencies
        run: composer install

      - name: Run tests
        run: vendor/bin/phpunit

Otro ejemplo: Deploy automático

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/app
            git pull origin main
            composer install --no-dev
            php artisan migrate --force

Para aprender sobre CI/CD, revisa nuestra Ruta DevOps CI/CD.

Parte 7: Siguientes Pasos

1. Practica el flujo básico

El flujo que usarás el 90% del tiempo:

git checkout -b feature/mi-funcionalidad
# Trabajar, hacer cambios...
git add .
git commit -m "feat: descripción del cambio"
git push -u origin feature/mi-funcionalidad
# Crear Pull Request en GitHub

2. Aprende Git Flow

Git Flow es una estrategia de ramas profesional:

main (producción)
├── develop (desarrollo)
│   ├── feature/login
│   ├── feature/dashboard
│   ├── hotfix/security-bug
│   └── release/v2.0

3. Configura tu repositorio profesional

# Inicializar
git init

# Crear .gitignore antes de empezar
# Configurar pre-commit hooks
# Agregar README.md con instrucciones
# Crear LICENSE si es open source

4. Sigue la Ruta del Ninja

En 8devmx tenemos rutas de aprendizaje para Git:

Resumen de esta guía:

ConceptoImportanciaFrecuencia de uso
init, add, commitEsencialDiaria
status, log, diffEsencialDiaria
branch, checkoutEsencialDiaria
mergeEsencialSemanal
push, pull, cloneEsencialDiaria
Resolver conflictosEsencialSemanal
rebaseMuy importanteSemanal
stashImportanteSemanal
.gitignoreEsencialAl inicio
Pull RequestsEsencialSemanal
Code ReviewEsencialSemanal
Cherry-pickModeradoRara vez
reset/revertImportanteMensual
GitHub ActionsImportanteAl configurar

Total estimado: 1-2 meses para dominar el flujo de trabajo profesional.

Git es la herramienta que usarás todos los días como desarrollador. Al principio parecerá compleja, pero después de unas semanas, los comandos básicos serán segunda naturaleza. La clave es hacer commits frecuentes con mensajes claros, y nunca hacer push a main directamente.