DOMINICODE

Tag: Git

  • Aprende Git: Guía Práctica

    Aprende Git: Guía Práctica

    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.