Arquitectura del Software - Software architecture
-
|
Tenemos varias ramas "muertas", y si seguimos sin borrarlas tendremos un gran número de ellas. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
En mi opinión, no hay una norma clara y depende un poco de cómo queráis tener el repositorio. Si son ramas que ya se han mezclado con la rama máster, quizá no hay problema en borrarlas, pero si son ramas muertas que no se van a mezclar, igual es bueno mantenerlas. Por ejemplo, si un miembro del equipo crea una rama para hacer una prueba en Python y luego ese código no se utiliza, puede ser bueno dejarla abierta para demostrar que ha realizado dicha contribución. |
Beta Was this translation helpful? Give feedback.
-
|
Sí, me refiero a ramas que ya han sido mezcladas en develop/master, por lo tanto su historial de commits ya está en el arbol principal. |
Beta Was this translation helpful? Give feedback.
-
|
Un factor también a tener en cuenta es como "mezcláis" las ramas a develop/master. Según lo hagáis se puede perder ese historial de commits, que puede ser interesante mantener, en ciertos casos. Os recomiendo ver este video que lo explica muy bien: |
Beta Was this translation helpful? Give feedback.
-
|
Gracias por la respuesta. Para el primer entregable haciamos squash merge que perdia los commits, pero hemos abandonado esa metodología desde la última entrega. |
Beta Was this translation helpful? Give feedback.
En mi opinión, no hay una norma clara y depende un poco de cómo queráis tener el repositorio.
Si son ramas que ya se han mezclado con la rama máster, quizá no hay problema en borrarlas, pero si son ramas muertas que no se van a mezclar, igual es bueno mantenerlas. Por ejemplo, si un miembro del equipo crea una rama para hacer una prueba en Python y luego ese código no se utiliza, puede ser bueno dejarla abierta para demostrar que ha realizado dicha contribución.