Trabajar con Git
Imagina que empiezas tu jornada. Tienes un proyecto con algunos archivos y necesitas hacer algo: añadir una función nueva, corregir un bug, etc. Además, quieres mantenerlo bajo control de versiones.
Como resultado, se crearán algunos archivos nuevos y se modificarán o eliminarán algunos archivos existentes. El directorio de trabajo de tu proyecto cambiará.
Ah, sí: esa es jerga de Git para hablar de los archivos del proyecto. Vamos a dedicarle un momento.
El (working tree, a veces traducido literalmente como árbol de trabajo) es el conjunto real de archivos de tu proyecto en su estado actual. Es la versión del proyecto que ves delante y con la que trabajas. Cuando alguien habla de cambios en el directorio de trabajo, se refiere a cambios que has hecho en archivos pero que aún no has guardado en Git. Pueden ser archivos nuevos, modificaciones y eliminaciones.
Has trabajado en tu proyecto y ahora tienes cambios en el directorio de trabajo. Ya puedes guardar tu progreso. Pero antes tienes que revisar esos cambios y decidir cuáles quieres conservar.
En este punto, Git puede mostrarte qué archivos han cambiado y qué líneas se han añadido, eliminado o modificado. Puedes revisar esos cambios, añadir los que quieras al área de preparación (staging area) y descartar los que no.
El es la memoria a corto plazo de Git: el lugar donde registra qué cambios has seleccionado para la siguiente instantánea del proyecto (en la jerga de Git, un commit; ahora volvemos a eso).
Imagina que me he pasado todo el día trabajando en un cambio grande del proyecto y, ahora que he terminado, quiero guardar esos cambios de forma permanente en el historial. Quiero crear un de Git: una instantánea del estado actual de los archivos del proyecto. Cuando se crea un commit, pasa a formar parte del historial del proyecto y no se puede cambiar ni eliminar fácilmente.
Pero antes de crearlo tienes que decidir exactamente qué cambios deben entrar en el próximo commit. La mayoría de las veces serán todos los cambios que has hecho. Pero a veces conviene dividirlos en varios commits para mantener ordenado el historial del proyecto. Entonces añades solo una parte de los cambios al área de preparación, creas el commit y repites el proceso con el resto.
Analogía: has lavado el coche y también has rellenado el líquido limpiaparabrisas. Son dos cambios independientes, así que es mejor registrarlos en commits separados. Si no, el historial de cambios del depósito del limpiaparabrisas contendrá una entrada de "Lavé el coche", que no describe muy bien lo que cambió y puede confundir a quien lea ese historial más adelante.
Cuando ya has elegido y organizado los cambios que quieres conservar, solo queda crear el commit. Dentro del commit también puedes dejar una descripción que explique exactamente qué cambió y por qué. Eso hace que el historial del proyecto sea más fácil de entender cuando tú u otra persona lo revise más adelante. Cuando se crea el commit, esos cambios quedan guardados de forma permanente en el repositorio de Git (más jerga de Git para decir "historial del proyecto").
Un es la memoria a largo plazo de Git. Cada commit que creas pasa a formar parte del repositorio.
Algunos commits pueden formar parte del historial principal de tu proyecto, otros pueden estar en ramas experimentales, otros pueden ser commits temporales que luego descartas, etc. Un commit puede ser tan pequeño como corregir una errata en una sola línea de código, o tan grande como añadir una función completa con cientos de archivos cambiados.
El repositorio se guarda en el directorio .git, en la raíz de tu proyecto. Ten en cuenta que este directorio está oculto por defecto. Si dañas o eliminas este directorio, corromperás tu repositorio Git local.
Aunque puedes parar aquí y tener un historial local completo de tu proyecto, el siguiente paso suele ser sincronizar con un repositorio remoto: enviar cambios con git push y traerlos e integrarlos con git pull.
Si trabajas en equipo, así compartes tus cambios con otras personas y recibes también sus actualizaciones. Tus nuevos commits se subirán al repositorio remoto, y descargarás los commits que tu equipo haya enviado desde la última sincronización.
Si trabajas por tu cuenta, sigues teniendo la ventaja de no perder tu trabajo si le pasa algo a tu ordenador, y puedes acceder al proyecto desde cualquier dispositivo. También puedes compartir tu código con otras personas dándoles acceso al repositorio remoto.
-
Vuelve al paso 2 si tienes más código terminado y listo para guardarse en el historial del proyecto. Prepara más cambios y crea commits con ellos. También puedes descartar cualquier cambio sin preparar que quede, si hace falta.
-
Vuelve al paso 1 si quieres seguir trabajando en tu proyecto y hacer más cambios en el directorio de trabajo.
Al principio, todo esto puede parecer un poco confuso, sobre todo si no has trabajado antes con control de versiones. Pero con el tiempo el proceso empieza a sentirse natural y acabarás haciendo casi todo de forma automática.
Haz el curso como estaba pensado: progreso en pequeñas dosis, un orden lineal y sin distracciones, y entradas de Gitopedia que se desbloquean poco a poco. Continúa con Git real en VS Code/Cursor/Antigravity/Windsurf cuando quieras.
pero requiere iniciar sesión