Cuando trabajamos con Git, una de las mejores prácticas para mantener nuestro código organizado y evitar conflictos es utilizar un workflow basado en ramas de características, o feature branches. Esto nos permite desarrollar nuevas funcionalidades o hacer cambios en paralelo sin afectar la rama principal, que normalmente es master.
Imaginemos que tenemos nuestro proyecto en la rama master y queremos hacer algunos cambios estéticos en la página web, como modificar la tipografía y los colores de la parte superior. En lugar de trabajar directamente sobre master, creamos una nueva rama para estos cambios. Para ello, usamos el comando git checkout para cambiar a esa rama, que llamaremos feature new style. De esta forma, podemos trabajar en paralelo mientras la rama master permanece intacta.
Abrimos nuestro editor de texto y realizamos las modificaciones necesarias en los archivos correspondientes. Por ejemplo, cambiamos el color de fondo y la tipografía para darle un aspecto más atractivo a la página. Una vez que hemos terminado, comprobamos el estado del repositorio con git status y añadimos todos los archivos modificados al área de preparación con git add .. Este comando es un atajo que añade todos los cambios realizados.
Después, hacemos un commit con un mensaje claro y descriptivo, por ejemplo:
git commit -m "Retoca el estilo de la página"
Es importante que el mensaje del commit explique qué hemos cambiado y por qué, para que cualquiera que revise el historial pueda entender fácilmente el propósito de ese cambio.
Si ahora consultamos el historial con git log, veremos que la rama feature new style apunta a este nuevo commit, mientras que la rama master sigue apuntando al commit anterior. Esto significa que tenemos dos líneas de desarrollo paralelas.
Para visualizar mejor esta situación, podemos usar:
git log --all --graph --oneline
Esto nos mostrará un gráfico con las ramas y sus respectivos commits, evidenciando que feature new style y master están en puntos diferentes del historial.
Cuando cambiamos de rama con git checkout master, Git actualiza nuestro directorio de trabajo para reflejar el estado de esa rama. Por eso, los archivos vuelven a su versión anterior, y la página web se muestra como estaba antes de los cambios estéticos.
Supongamos que, mientras trabajamos en la rama de estilo, recibimos una petición urgente del cliente para corregir la fecha de apertura de la web, que ha cambiado de octubre a noviembre. Como esta corrección es urgente y afecta a la rama principal, nos cambiamos a master y hacemos la modificación directamente ahí.
Editamos el archivo correspondiente, por ejemplo index.html, cambiando la fecha a 1 de noviembre. Luego añadimos el archivo y hacemos un commit con un mensaje claro:
git add index.html
git commit -m "Retrasa la apertura de la web"
Ahora, en el historial, tenemos dos ramas con commits diferentes: la rama feature new style con los cambios estéticos y la rama master con la corrección de la fecha. Ambas ramas han avanzado de forma independiente.
Para integrar los cambios de la rama de estilo en master, tendremos que fusionarlas más adelante, pero por ahora hemos visto cómo trabajar con commits en ramas paralelas, manteniendo el historial limpio y organizado.
Este enfoque nos permite desarrollar nuevas funcionalidades o hacer correcciones urgentes sin interferir con el trabajo que se está realizando en otras ramas, facilitando la colaboración y el mantenimiento del proyecto.