Git permite registrar la evolución de un proyecto y trabajar en líneas de cambio independientes. Esta guía reúne un flujo habitual desde la configuración inicial hasta la colaboración mediante ramas y remotos, y aclara cómo deshacer operaciones sin perder trabajo por accidente [1].
Configurar e iniciar un repositorio
Configura el nombre y el correo que aparecerán en los commits. La opción --global aplica estos valores a todos los repositorios del usuario; omítela si necesitas una configuración específica para el proyecto [2].
git config --global user.name "Tu Nombre"
git config --global user.email "tu-correo@example.com"
git config --list
Para trabajar sobre un repositorio existente, clónalo. Para iniciar uno en una carpeta local, usa git init:
git clone <URL_DEL_REPOSITORIO>
cd <CARPETA_DEL_REPOSITORIO>
# Alternativa: iniciar un repositorio en la carpeta actual
git init
Después de modificar archivos, revisa el estado, añade al área de preparación los cambios que quieras incluir y crea un commit descriptivo:
git status
git add <ARCHIVO>
git diff --staged
git commit -m "Describe el cambio"
git add . añade los cambios detectados bajo la carpeta actual. Antes de confirmar, git diff --staged permite comprobar qué contenido se incluirá en el commit [1].
Ramas y fusiones
Una rama permite desarrollar un cambio sin incorporarlo todavía a la rama principal. En Git moderno, switch expresa claramente la operación de cambiar o crear una rama [3]:
git branch # listar ramas locales
git switch -c mejora/documentacion # crear y cambiar
git switch main # cambiar a otra rama
git branch -d mejora/documentacion # borrar rama ya integrada
Para integrar una rama, sitúate primero en la rama de destino y fusiónala:
git switch main
git merge mejora/documentacion
Si hay conflictos, Git deja los archivos afectados para que los edites. Tras resolverlos, revisa el resultado, añade los archivos y completa el commit de fusión. Si la fusión aún no se ha completado y quieres cancelarla, usa git merge --abort [4].
Deshacer cambios con cuidado
Git distingue entre cambios del directorio de trabajo y cambios preparados para el próximo commit. restore permite actuar explícitamente sobre cada área [5]:
# Quitar un archivo del área de preparación, conservando sus cambios
git restore --staged <ARCHIVO>
# Descartar los cambios locales no confirmados de un archivo
git restore <ARCHIVO>
Cuidado: el segundo comando descarta los cambios sin confirmar de ese archivo. Revisa
git statusy guarda una copia o un commit antes de usarlo si no estás seguro.
Consulta el historial con:
git log --oneline --graph --decorate --all
Para inspeccionar un commit sin mover una rama, puedes abrirlo en estado separado (detached HEAD). Si decides continuar trabajando desde ese punto, crea una rama antes de cambiar de referencia [6]:
git switch --detach <ID_DEL_COMMIT>
git switch -c experimento <ID_DEL_COMMIT>
Trabajar con repositorios remotos
Un clon suele configurar origin para el repositorio del que procede. Puedes consultar los remotos y actualizar referencias sin modificar la rama de trabajo mediante fetch [7]:
git remote -v
git fetch origin
git branch --all
git pull descarga cambios y luego los integra en la rama actual. Según la configuración, esa integración puede hacerse mediante merge o rebase. Si quieres controlar los pasos por separado, ejecuta fetch y luego integra la rama remota explícitamente [7]:
git fetch origin
git merge origin/main
Para compartir una rama nueva, publica la rama y establece su seguimiento remoto:
git push -u origin mejora/documentacion
No presupongas que la rama principal remota se llama master: comprueba el nombre configurado en el repositorio y en el servicio de alojamiento.
Fork, upstream y rebase
Cuando trabajas desde un fork, conserva dos remotos: origin para tu copia y upstream para el proyecto original. Descarga los cambios de upstream y rebasea la rama de trabajo sobre la rama principal actualizada [8]:
git remote add upstream <URL_DEL_REPOSITORIO_ORIGINAL>
git fetch upstream
git switch main
git merge --ff-only upstream/main
git switch mejora/documentacion
git rebase main
Si el rebase genera conflictos, resuélvelos y continúa:
git status
git add <ARCHIVO_RESUELTO>
git rebase --continue
Si ya habías publicado la rama antes de reescribir su historial, puede ser necesario actualizarla en el remoto. Usa --force-with-lease únicamente cuando el equipo permita reescribir esa rama: Git comprueba que la referencia remota sigue en el estado esperado y reduce el riesgo de sobrescribir trabajo ajeno [9]. Evita usar --force a ciegas.
Etiquetas y cambio de rama principal
Las etiquetas identifican puntos concretos del historial, por ejemplo una versión publicada. Una etiqueta anotada guarda además metadatos y un mensaje [10]:
git tag -a v1.0.0 -m "Versión 1.0.0"
git tag
git push origin v1.0.0
Cambiar el nombre de la rama principal requiere coordinar el repositorio local con el alojamiento y los colaboradores. Renombrar la rama local y publicarla no actualiza por sí solo la rama predeterminada del servidor: cambia esa configuración en el alojamiento, actualiza los clones y, cuando ya no queden dependencias, elimina la referencia antigua [11].
En resumen
- Revisa
git statusygit diff --stagedantes de crear un commit. - Usa
git switchpara cambiar de rama ygit restorepara recuperar archivos de forma explícita. - Distingue
fetch, que descarga referencias, depull, que además integra cambios. - Rebasea ramas compartidas solo cuando el flujo del equipo lo permita; protege las actualizaciones forzadas con
--force-with-lease. - Trata las operaciones que descartan cambios o reescriben historial como potencialmente destructivas.
📚 Fuentes consultadas
- Git Book — Recording Changes to the Repository
- git-config — documentación oficial
- git-switch — documentación oficial
- Git Book — Basic Branching and Merging
- git-restore — documentación oficial
- git-checkout — documentación oficial, estado detached HEAD
- Git Book — Working with Remotes
- Git Book — Rebasing
- git-push — documentación oficial
- Git Book — Tagging
- Git Book — Branch Management