Comando Básicos de Git

por | Feb 23, 2026 | Guías y Roadmaps

Comandos Básicos Git

¿Qué es Git vs GitHub?

  • Git: control de versiones local.
  • GitHub: hosting remoto + PRs, issues, acciones, etc.

Comenzando con Git y Github

Esta guía explica cómo usamos Git y GitHub en proyectos profesionales: flujo de ramas, commits, Pull Requests, despliegue y buenas prácticas.

Setup Inicial

Comandos Base:

  • git config --global user.name
  • git config --global user.email
  • git config --global init.defaultBranch main
  • ssh-keygen + añadir key en GitHub (opcional pero recomendado)
  • git config --global pull.rebase false (o true, según flujo)

Crear repo y primer push

  • git init
  • git add .
  • git commit -m "Initial commit"
  • git branch -M main
  • git remote add origin <url>
  • git push -u origin main

Convención de nombres (repos, ramas, PRs) — válida para cualquier proyecto

Repositorio

nombre-proyecto (simple y sin espacios)
Ej.: traffic-light-system, planning-portal-backend

Ramas (estándar)

  • main o master → producción
  • dev → integración
  • feature/descripcion-corta → nueva funcionalidad
  • fix/descripcion-corta → bug en desarrollo
  • hotfix/descripcion-corta → bug urgente en producción
  • chore/descripcion-corta → mantenimiento (deps, scripts)

Pull Requests (PR)

Nombre del PR = frase corta y clara, idealmente con prefijo:

  • [FEAT] Añade login con Google
  • [FIX] Corrige error 500 en /api/projects
  • [REFACTOR] Simplifica validador de estados
  • [CHORE] Actualiza dependencias

Regla práctica: que alguien que no tocó el código entienda el PR en 3 segundos.

Ejemplos:

  • feature/login-google
  • fix/error-500-endpoint
  • hotfix/pago-stripe-timeout

Cambio recomendado: usar main en vez de master (opcional)

git branch -M main
git checkout -b dev

Y donde decía master, cambiarlo por main.

Cómo dejarlo “universal” en la guía

  • git branch -M main «renombramos la rama Master a Main»
  • git checkout -b dev «creamos la rama dev»

“Ejemplo: en el proyecto se llama app-nueva, el repo llamarlo igual app-nueva.”

Flujo diario de trabajo

Traer un repositorio de GitHub a local (clonar)

Dentro de Flujo diario lo primero es “tener el repo en local”. Aquí explicamos cómo clonar y luego el ciclo típico pull → cambios → commit → push.

Opción 1: Clonar por HTTPS (rápido y simple)

cd /ruta/donde/quieres/el-proyecto
git clone https://github.com/USUARIO/REPO.git
cd REPO
  • Te pedirá credenciales al hacer push. En GitHub hoy se usa token (no contraseña) si te lo pide.

Opción 2: Clonar por SSH (recomendado si trabajas mucho)

cd /ruta/donde/quieres/el-proyecto
git clone git@github.com:USUARIO/REPO.git
cd REPO

Verificar que quedó bien conectado

git remote -v

Deberías ver origin apuntando a GitHub.

Flujo diario típico (una vez clonado)

1) Traer cambios del remoto antes de trabajar

git pull

Si quieres hacerlo “más seguro” (ver antes qué llega):

git fetch
git status

2) Crear una rama para tu cambio

git switch -c feature/mi-cambio
# o: git checkout -b feature/mi-cambio

3) Hacer cambios y ver qué tocaste

git status
git diff

4) Guardar cambios (commit)

git add .
git commit -m "Explica qué hiciste"

5) Subir tu rama a GitHub

git push -u origin feature/mi-cambio

Luego abres un Pull Request en GitHub.

Caso común: ya tengo el repo pero quiero “sincronizarme” con main

git switch main
git pull

Si trabajas en una rama y quieres traer lo último de main:

git fetch origin
git merge origin/main
# o si usas rebase:
# git rebase origin/main