Git no lo utilizo solamente para guardar una copia del proyecto. Lo utilizo para organizar el trabajo, experimentar sin comprometer la versión estable y conservar un historial que permita saber qué ocurrió en cada etapa.
Mi flujo de trabajo
Un ciclo sencillo que adapto según el tamaño y las necesidades de cada proyecto.
Crear o actualizar una rama
Cuando trabajo en una funcionalidad nueva, prefiero mantener los cambios separados del código principal.
git switch -c feature/nueva-funcionalidadRevisar el estado
Antes de modificar o guardar cambios, revisar el estado del repositorio permite saber exactamente qué está ocurriendo.
git statusConstruir y probar
Los cambios deben probarse antes de convertirse en una versión que otros puedan utilizar.
npm run buildCrear un commit
El commit representa un cambio concreto y debería explicar de manera clara qué se modificó.
git commit -m "feat: nueva funcionalidad"Subir los cambios
Una vez revisados los cambios, los envío al repositorio remoto para conservarlos y compartirlos.
git push origin feature/nueva-funcionalidadIntegrar
Cuando el flujo lo requiere, los cambios pasan por revisión antes de integrarse a la rama principal.
Pull Request → Review → MergeEl ciclo básico
La secuencia que más utilizo cuando estoy trabajando en una funcionalidad.
MODIFICAR
REVISAR
PROBAR
COMMIT
PUSH
La idea es evitar llegar al commit sin saber qué cambió. Revisar y probar antes de guardar una versión hace que el historial sea mucho más útil.
Trabajar con ramas
Las ramas permiten separar una línea de trabajo de otra sin alterar inmediatamente la versión principal.
mainVersión principal y estable del proyecto.
feature/nueva-funcionalidadTrabajo aislado para desarrollar una nueva característica.
fix/error-formularioRama específica para corregir un problema.
git switch main
git pull
git switch -c feature/nueva-funcionalidad
# trabajar y probar
git add .
git commit -m "feat: nueva funcionalidad"
git push -u origin feature/nueva-funcionalidadCommits que expliquen el cambio
Un buen commit debería permitir entender rápidamente qué ocurrió.
Intento evitar mensajes demasiado genéricos como update o cambios. Cuando el historial crece, esos mensajes dejan de aportar información.
feat: agregar formulario de contactofix: corregir validación del formulariorefactor: separar lógica de autenticacióndocs: actualizar documentaciónchore: actualizar dependenciasComandos que más utilizo
No necesito memorizar cientos de comandos. Estos cubren buena parte de mi flujo diario.
git statusVer el estado actual del repositorio.git branchListar las ramas disponibles.git switch -c feature/nombreCrear y cambiar a una nueva rama.git add .Preparar los cambios para el commit.git commit -m "mensaje"Guardar un conjunto de cambios.git pullActualizar el repositorio local.git pushEnviar commits al repositorio remoto.git log --onelineConsultar el historial resumido.Local y remoto
Git permite trabajar localmente mientras GitHub puede funcionar como repositorio remoto y punto de colaboración.
LOCAL
Desarrollo, pruebas y commits en el equipo.
REMOTE
Repositorio remoto con el historial compartido.
COLABORACIÓN
Revisión e integración de cambios.
Tener el código en remoto también permite recuperar versiones anteriores, trabajar desde diferentes equipos y mantener una copia del historial del proyecto.
Reglas que intento mantener
Un flujo sencillo funciona mejor cuando existen algunas reglas claras.
Checklist antes del push
Una revisión rápida antes de subir los cambios puede evitar problemas innecesarios.
Git es parte del proceso, no solo una herramienta
Un buen flujo con Git ayuda a construir con mayor confianza. Permite experimentar, volver atrás, revisar decisiones y entender cómo evolucionó un proyecto. La clave no está en utilizar comandos complejos, sino en mantener un proceso ordenado y consistente.