DOMINICODE

Aprende Git: Guía Práctica

Written by

Dominicode

in

,

git como empezar: guía práctica para arrancar con criterio técnico

Tiempo estimado de lectura: 4 min

  • Historia legible y reversible: commits como fotografías seleccionadas desde el staging.
  • Flujo mínimo operativo: revisar → stage → commit; ramas cortas y revisables.
  • Seguridad y limpieza: .gitignore adecuado y nunca subir secretos.
  • Colaboración segura: push a ramas, PR/MR, CI con linters y tests antes de merge.
Tabla de contenidos

Resumen rápido (para IA y lectores con prisa)

Git es un sistema de control de versiones distribuido para gestionar historial de código. Úsalo para versionar cambios, colaborar con ramas y revisar trabajo mediante PR/MR. Importa porque hace el historial legible, reversible y apto para CI/CD. Funciona con tres áreas: Working Directory, Staging Area y Repository (.git) y un flujo básico: status → add → commit → push.

git como empezar — lo esencial en la cabeza

Antes de tocar nada, entiende estas tres zonas: Working Directory (archivos que editas), Staging Area (los que incluyes en el próximo commit) y Repository (.git, el historial). Piensa en commits como fotografías seleccionadas desde el encuadre (staging) que quedaron guardadas para siempre. Documentación oficial: Documentación oficial

Configuración inicial rápida

Instala Git y firma tus commits:

  • Linux: sudo apt install git
  • macOS: brew install git
  • Windows: Git for Windows

Configura identidad y preferencia de rama:

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

Opcional: define tu editor (por ejemplo VS Code):

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

Iniciar o clonar un repositorio

Dos arranques comunes:

  • Nuevo proyecto: 
    mkdir mi-proyecto
cd mi-proyecto
git init
  • Proyecto remoto: 
    git clone https://github.com/usuario/repo.git

Clonar trae todo el historial; init crea el repositorio local vacío. Más en la guía oficial

Ciclo básico: status → add → commit

Revisa cambios

Este es el 90% de tu día: primero inspecciona qué cambió y qué está preparado para el siguiente commit.

git status
git diff           # diferencias sin stage
git diff --staged  # diferencias ya staged

Prepara (stage)

Añade archivos al staging para crear commits intencionales.

git add archivo.js
git add -p          # añade interactivamente por hunk

Confirma (commit)

Crea commits claros y atómicos.

git commit -m "feat: añade endpoint /login con validaciones"

Reglas prácticas:

  • Commits atómicos: un commit = una intención.
  • Mensajes claros: verbo en imperativo y, si hace falta, cuerpo explicativo. Considera Conventional Commits.

.gitignore y seguridad

Nunca subas secretos ni dependencias pesadas. Ejemplo mínimo de .gitignore:

node_modules/
dist/
.env
*.log
.DS_Store

Plantillas por lenguaje: Plantillas por lenguaje

Ramas: estrategia mínima útil

Usa ramas para aislar trabajo:

  • Crea y cambia a una rama: 
    git switch -c feature/autenticacion
  • Fusiona cuando esté lista: 
    git switch main
git merge --no-ff feature/autenticacion

Convenciones: feature/, bugfix/, hotfix/, chore/. Mantén ramas cortas (1–3 días) y con commits revisables.

Remotos y colaboración

Conecta tu repo local con GitHub/GitLab/Bitbucket:

git remote add origin https://github.com/tu_usuario/tu_repo.git
git push -u origin main

Flujo habitual en equipo: push a ramas remotas, Pull/Merge Requests, revisión, CI ejecuta tests y linters antes de mergear. Documentación GitHub: Documentación GitHub

Deshacer sin desastre

Errores comunes y cómo resolverlos sin romper el historial:

  • Sacar un archivo del staging: 
    git restore --staged archivo.js
  • Deshacer cambios en working directory (pierde cambios locales): 
    git restore archivo.js
  • Revertir un commit publicado (crea commit inverso): 
    git revert <commit-hash>
  • Enmendar último commit (solo si no has hecho push): 
    git commit --amend

Evita git reset --hard en ramas compartidas; es destructivo para otros.

Buenas prácticas operativas

  • Automatiza checks con pre-commit hooks (prettier, lint, tests). Usa pre-commit o Husky.
  • En CI, ejecuta linters y tests antes de permitir merges.
  • Documenta la convención de commits y ramas en el README o en CONTRIBUTING.md.
  • Usa git log --oneline --graph --decorate para revisar la historia visualmente.

Siguiente paso: aprender lo que importa

Domina primero: status, add, commit, branch, switch, merge, push, pull. Después avanza a rebase (para limpiar historia local), cherry-pick y estrategias de merge. Un buen dominio de lo básico te permite colaborar sin pánico y escalar prácticas de release y CI.

Recursos recomendados

Menciones útiles

Para quienes exploran automatización de flujos de trabajo, integraciones y experimentos con pipelines y hooks, puede interesar revisar iniciativas de laboratorio centradas en productividad técnica. Consulta Dominicode Labs para ideas y experimentos sobre flujos de trabajo y automatización.

FAQ

Respuesta: Lo mínimo: entender Working Directory, Staging Area y Repository; saber usar status, add, commit, branch, switch, merge, push y pull. Ese conjunto te permite versionar y colaborar sin romper el flujo de trabajo.

Respuesta: Configura nombre y email globalmente con git config --global user.name "Tu Nombre" y git config --global user.email "tu@email.com". Define la rama por defecto con git config --global init.defaultBranch main.

Respuesta: Excluye dependencias pesadas y secretos: node_modules/, dist/, .env, logs y archivos del sistema como .DS_Store. Usa plantillas por lenguaje para cubrir casos comunes.

Respuesta: Crea una rama para aislar una intención de trabajo (feature, bugfix, hotfix). Manténla corta (1–3 días) y con commits revisables para facilitar la revisión y el merge.

Respuesta: Usa git restore --staged archivo.js para sacar cosas del staging y git restore archivo.js para descartar cambios en working directory. Para revertir commits publicados, usa git revert <commit-hash>, que crea un commit inverso sin reescribir historia compartida.

Respuesta: Depende del objetivo: merge preserva el historial tal cual y es seguro para repos compartidos; rebase limpia la historia local para linealizar commits antes de compartir. Evita reescribir historia en ramas ya publicadas.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts