This content originally appeared on DEV Community and was authored by Raül Martínez i Peris
Índice:
- Sección A. Estructurar un proyecto: apartado I, apartado II, apartado III, apartado IV, apartado V, apartado VI, apartado VII, apartado VIII.
Como hemos comentado en anteriormente, hemos cometido un par de errores en los archivos Dockerfile.
Ahora debemos corregirlo, pero, queremos hacerlo en la rama correspondiente y llevar los cambios a main.
¿Qué ocurre si no estamos en un estado 'limpio'?
Antes de continuar, como es habitual, debes estar sin ningún cambio en el repositorio: nunca debes empezar a trabajar teniendo código a medias, en ninguna rama.
Si estás trabajando y surge una urgencia que te obliga a dejar a medias un trabajo, tienes varias opciones:
- Guardar el trabajo para continuar después sin ensuciar el histórico. Esta es la mejor opción.
- Descartar lo trabajado.
- Crear un commit (indicando claramente que el trabajo no está terminado). Esto es una mala opción.
Veamos la opción 1, cómo guardar el trabajo sin hacer commit:
git add .
git stash
Esto realiza un 'commit interno' que no existe en el histórico de las ramas.
Para consultar los commit internos que tienes en stash:
git stash list
Para recuperar el último commit interno que tienes en el stash:
git stash apply
Hay más opciones muy interesantes, revisa la documentación de git.
Sincronizar la copia local
Sabiendo que no tenemos código a medias, lo primero es tener actualizadas las ramas involucradas.
Nos situamos en main y la actualizamos:
git checkout main
git pull
Nos situamos en release/000-virtualization y la actualizamos:
git checkout 'release/000-virtualization'
git pull
Realizar los cambios y hacer el commit
Ahora realizaremos las correcciones de los errores que cometimos.
En el archivo Dockerfile:
- Busca
APP_FOLDERy sustituyelo porAPP_PATH.
En el archivo Dockerfile.windows:
- Busca
APP_FOLDERy sustituyelo porAPP_PATH. - Busca
APP_VIRTUALIZATIONy sustituyelo porAPP_ENV.
Ahora realizamos el commit:
git add .
git commit -m 'Correcciones en los archivos Dockerfile'
Preparar la rama y subir los cambios
Primero nos traemos la rama main a la nuestra:
git merge main
Si existe algún conflicto git te lo avisará. Si esto ocurre tendrás que resolverlo, y hacer un nuevo commit.
Ahora debemos subir los cambios a origin:
git push origin 'release/000-virtualization'
Te estarás preguntando porqué hicimos el merge después de hacer los cambios y el commit. La explicación es sencilla: queremos tener en nuestra rama lo último que entró en main porque después debemos realizar el merge request y para que no haya problemas añadidos deberíamos tener lo último. Por ello, cuanto más tiempo pasa entre tu merge de main y tu push a origin , más posibilidades de que no sea lo último. Yo personalmente hago un merge antes de empezar y otro después, lo cual me garantiza trabajar sobre lo último y asegurarme que es lo último con lo que hago la petición de MR.
Crear el Merge Request
Esta parte ya sabes como funciona, lo vimos en un artículo anterior. Haz el MR y después descárgate a main los cambios.
Apuntes
Merge vs Rebase
En git hay una regla de oro: nunca hagas un rebase en ramas compartidas o públicas.
Estas son las razones:
- Preservación del historial (acción no destructiva): con
git mergepreservamos el historial de forma cronológica y real. - Seguridad en el trabajo en equipo: la utilización de
git mergeno reescribe los commit por lo que es fácil llevar un seguimiento rápido y limpio. Sin embargo, el uso degit rebasereescribe el historial de la rama, por lo que en cualquier otro clonado existente del repositorio los ID's de los commits serán diferentes, provocando en el resto del equipo un considerable costo de tiempo revisando lo ocurrido. - Claridad en las auditorías de código: cuando utilizamos
git merge, la utilización de herramientas comogit bisectse facilita enormemente al mostrar exactamente qué ocurrió y cuando.
Enlaces
Repositorio del proyecto:
Enlaces de interés:
- Sobre los entornos: en https://gitlab.com/elferrer/la_fragua/-/blob/main/README.md?ref_type=heads#docker-compose encontrarás información sobre cómo utilizar los diferentes entornos de desarrollo/producción en Linux/Windows.
- Git stash: https://git-scm.com/docs/git-stash
This content originally appeared on DEV Community and was authored by Raül Martínez i Peris
Raül Martínez i Peris | Sciencx (2025-10-04T15:19:19+00:00) Python. Project Structure (VII). Retrieved from https://www.scien.cx/2025/10/04/python-project-structure-vii/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.