Cuando trabajamos con Git, es fundamental entender qué ocurre detrás de cada commit y por qué necesitamos realizar ciertos pasos para registrar nuestros cambios. En primer lugar, tenemos el directorio de trabajo, que es la carpeta donde hacemos todas nuestras modificaciones. Cuando creamos un commit, Git guarda un estado concreto de esos archivos, pero antes de llegar a ese punto, hay un paso intermedio muy importante: el área de staging o stage.
El stage es un espacio temporal donde colocamos los cambios que queremos incluir en nuestro próximo commit. Esto se hace con el comando git add, que puede aplicarse a archivos específicos o a todos los cambios con un punto (git add .). La utilidad principal de esta etapa es que nos permite seleccionar con precisión qué modificaciones queremos confirmar, lo que resulta especialmente útil cuando hemos hecho varios cambios y queremos organizarlos en commits separados y atómicos.
Para visualizar el historial de commits, usamos git log, que nos muestra una lista con cada commit realizado, identificados por un hash SHA1 único. Este hash se genera a partir del contenido del commit, incluyendo el mensaje y los archivos, lo que garantiza la integridad y unicidad de cada cambio. Si alguien intentara modificar un commit anterior, Git detectaría la inconsistencia en el hash, asegurando así la seguridad del historial.
Cuando hacemos cambios en nuestro directorio de trabajo, Git nos indica con git status si hay modificaciones que aún no están en el stage. Por ejemplo, si editamos un archivo y añadimos una línea como estamos en construcción, ese cambio aparecerá como modificado pero no staged. Para ver exactamente qué hemos cambiado, podemos usar git diff, que muestra las líneas añadidas en verde y las eliminadas en rojo.
Es importante entender que solo los cambios que hemos añadido al stage con git add serán incluidos en el siguiente commit. Si hacemos más modificaciones después de añadir un archivo al stage, esas nuevas modificaciones no se incluirán hasta que volvamos a hacer git add. Esto nos da un control muy fino sobre qué cambios confirmamos y cuáles dejamos para después.
En caso de que olvidemos añadir algún cambio antes de hacer un commit, Git nos ofrece una solución práctica con el comando git commit --amend. Este comando nos permite modificar el último commit, añadiendo los cambios que nos hayamos dejado fuera sin necesidad de crear un commit nuevo. Al hacer esto, el hash del commit cambia, reflejando que el contenido ha sido modificado. Sin embargo, esta operación solo es posible con el commit más reciente, ya que modificar commits anteriores implicaría cambiar toda la cadena de commits posteriores, lo que es mucho más complejo y requiere técnicas avanzadas como la reescritura del historial.
En resumen, el flujo habitual con Git implica trabajar en el directorio de trabajo, seleccionar los cambios que queremos confirmar con git add para colocarlos en el stage, y finalmente hacer el commit con git commit. Este proceso nos da flexibilidad y control para mantener un historial limpio y organizado, facilitando la colaboración y el mantenimiento de nuestros proyectos.