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.
Mientras trabajas, crearás algunos archivos y modificarás o eliminarás otros. El directorio de trabajo de tu proyecto cambiará.
Ah, sí: esa es jerga de Git para hablar de los archivos del proyecto. Vamos a aclararlo.
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 tienes 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.
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 staging (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. Ahora que he terminado, quiero guardarlo de forma permanente en el historial. Para eso creo un de Git: una instantánea del estado actual de los archivos del proyecto. Una vez creado, el commit pasa a formar parte del historial y no se puede cambiar ni eliminar fácilmente.
Pero antes de crearlo tienes que decidir exactamente qué cambios deben entrar en el siguiente commit. Lo normal es incluir todos los que has hecho, aunque a veces conviene dividirlos en varios commits para mantener ordenado el historial del proyecto. En ese caso, añades solo una parte de los cambios a staging, 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 crear un commit distinto para cada uno. 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.
Con los cambios que quieres conservar ya elegidos y organizados, solo queda crear el commit. También puedes añadir una descripción que explique exactamente qué cambió y por qué. Así será más fácil entender el historial cuando alguien lo revise más adelante, seas tú u otra persona. Al crear 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, de ramas experimentales; y otros pueden ser temporales y acabar descartados. 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 que cambie cientos de archivos.
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 local.
Aunque podrías detenerte aquí y conservar un historial local completo del proyecto, lo habitual es sincronizarlo después con un repositorio remoto: subir cambios con git push y traerlos e integrarlos con git pull.
Si trabajas en equipo, así compartes tus cambios y recibes los del resto. Subirás tus nuevos commits al repositorio remoto y traerás los que haya publicado tu equipo desde la última sincronización.
Si trabajas por tu cuenta, el repositorio remoto también evita que pierdas el trabajo si le pasa algo a tu ordenador y te permite acceder al proyecto desde cualquier dispositivo. Además, puedes compartir tu código dando acceso al repositorio a otras personas.
-
Vuelve al paso 2 si ya tienes más código listo para guardarlo en el historial del proyecto. Añade más cambios a staging y crea commits con ellos. También puedes descartar los cambios que queden fuera de staging, 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 te resultará natural y acabarás haciendo casi todo de forma automática.
Haz el curso como se pensó: avanza poco a poco y en orden, sin distracciones, mientras desbloqueas nuevas entradas de Gitopedia. Cuando quieras, continúa practicando con Git de verdad en VS Code, Cursor o Antigravity IDE.
pero requiere iniciar sesión