Definición
Git es un sistema de control de versiones: guarda el historial completo de los cambios de un proyecto, quién hizo cada uno y cuándo, y permite volver atrás, comparar versiones o trabajar en varias cosas a la vez sin mezclarlas.
Aclaración que hace falta constantemente: Git no es GitHub. Git es el programa que corre en tu ordenador. GitHub, GitLab o Bitbucket son sitios web donde alojar repositorios de Git y colaborar. Puedes usar Git sin GitHub perfectamente.
Es distribuido: cada copia del repositorio contiene el historial entero. No hay un servidor central imprescindible, y por eso puedes trabajar y hacer commits sin conexión.
Los conceptos que hay que entender
Repositorio. La carpeta del proyecto más el historial, guardado en una subcarpeta oculta.
Commit. Una foto del proyecto en un momento, con un mensaje que explica qué cambió y por qué. Es la unidad del historial.
Área de preparación (staging). El paso intermedio que confunde al principio: eliges qué cambios entran en el próximo commit antes de hacerlo. Permite separar dos cosas distintas que tocaste a la vez.
Rama (branch). Una línea paralela de trabajo. Creas una para una funcionalidad, trabajas ahí sin tocar la principal y luego la fusionas.
Fusión (merge). Juntar dos ramas. Si las dos tocaron las mismas líneas, aparece un conflicto que hay que resolver a mano.
Remoto. La copia en un servidor. push sube tus commits, pull baja los de los demás.
El flujo diario
git status # qué he tocado
git add fichero.php # preparar
git commit -m "Arregla el cálculo del margen"
git pull # traer lo de los demás
git push # subir lo mío
Y para trabajar en algo nuevo sin romper lo que funciona:
git switch -c precios-especiales # rama nueva
# ... trabajar, commits ...
git switch main
git merge precios-especiales
Ejemplo práctico
Trabajando solo, la tentación es pensar que Git no hace falta. Es justo al revés: cuando trabajas solo, Git es tu única red de seguridad.
Los tres momentos en que me ha salvado, y son los mismos que le pasan a todo el mundo:
Volver atrás sin drama. Un cambio que parecía bueno resulta que rompió otra cosa. Con historial, git revert deshace ese commit concreto y ya está. Sin historial, tratas de recordar qué tocaste.
Encontrar cuándo se rompió algo. Una función lleva semanas fallando y nadie sabe desde cuándo. git log sobre ese fichero enseña los últimos cambios y normalmente la respuesta salta a la vista.
Entender por qué está escrito así. git blame sobre una línea rara te dice quién la escribió y con qué mensaje de commit. Muchas veces ese mensaje explica una decisión que hoy parece absurda y en su momento tenía sentido.
Ese último caso es el que más valor da a los mensajes de commit. Un historial lleno de "cambios", "arreglo" y "ya" no sirve para nada. Un mensaje que dice qué problema resolvía vale su peso en oro dos años después.
Buenas costumbres
- Commits pequeños y con un solo tema. Uno que arregla un fallo y otro que cambia el diseño, no los dos juntos.
- Mensajes que expliquen el porqué, no el qué. El qué ya se ve en el cambio.
- Rama por funcionalidad. Nunca trabajes directamente sobre la rama principal en algo que puede quedar a medias.
- Un
.gitignoredesde el primer commit. Fueranode_modules, ficheros de configuración con credenciales, carpetas de compilación. pullantes de empezar. Los conflictos son mucho más pequeños si te sincronizas a menudo.
Errores comunes
- Subir credenciales. Es el error grave. Y borrarlas en un commit posterior no las quita del historial: siguen ahí para siempre. Si pasa, hay que rotar la clave, no solo borrarla.
- Commits gigantes que tocan cuarenta ficheros. Imposibles de revisar y de revertir.
- Miedo a las ramas. Son baratísimas en Git. Crear una no cuesta nada.
git push --forcesobre una rama compartida. Puedes borrar el trabajo de otro. Si hace falta,--force-with-lease.- Usarlo como copia de seguridad de ficheros grandes. Git guarda cada versión: mete un vídeo de 200 MB dos veces y el repositorio pesa 400 MB para siempre.
- No hacer commit hasta que "esté terminado". Entonces se pierde el sentido: el historial son los pasos, no solo el final.
Cuándo usarlo
Siempre, en cualquier proyecto de más de un fichero, aunque trabajes solo y aunque no vayas a publicarlo. Es de las pocas herramientas del oficio que no tienen alternativa razonable ni discusión.
