
Somos un equipo de un par de desarrolladores que tienen nuestra rama maestra y desarrollan funciones en ramas de funciones. Cuando liberamos, liberamos ramas de master. Todas las correcciones de errores se realizan en master y luego se seleccionan en la rama de versión correspondiente.
Queremos tener confirmaciones de fusión atómica para cada característica nueva que podamos revertir y dividir en dos como se describe enhttps://gist.github.com/jbenet/ee6c9ac48068889b0912. Debería darnos una historia como esta.
* aa55ffe - (HEAD, master) D
* 88425f8 - C
* 7bc519f - Merge branch 'feature-X' into master
|\
| * 9364e61 - feature-X: 2
| * bc76674 - feature-X: 1
|/
* 88425f8 - B
* 7bc519f - Merge branch 'feature-Y' into master
|\
| * 0e0deea - feature-Y: 4
| * 11079b5 - feature-Y: 3
| * 9364e61 - feature-Y: 2
| * bc76674 - feature-Y: 1
|/
* c765ae3 - A
Nuestro problema surge cuando tenemos varios desarrolladores trabajando en la misma función de seguimiento de nuestra versión remota de la rama de funciones. Porque si bien algunos desarrolladores trabajan en esa función, la corrección de errores puede ocurrir durante el desarrollo de una función en master. Ahora queremos incluir esas correcciones de errores en la rama de funciones (es decir, cambiar la base de la rama de funciones de un nuevo estado en master donde se soluciona el error).
¿Hay alguna manera de hacer esto que no incluya corromper la rama de seguimiento remoto y, por lo tanto, arruinar el historial limpio y las otras copias de trabajo de los desarrolladores de funciones?
Fx ¿Se podría seleccionar el error en la rama de características y hacer que git lo resuelva automáticamente después de la rebase final donde dejamos huérfana la rama de seguimiento remoto justo antes de fusionar la nueva versión rebasada de la rama de características en master?
Respuesta1
¿Se podría seleccionar el error en la rama de funciones y hacer que git lo resuelva automáticamente?
Esto puede funcionar si su solución no presenta conflictos. git clone https://gist.github.com/jbenet/7959265
, mira el historial y lee el reflog que pegué allí.
Si resuelve el conflicto al seleccionarlo, puede eliminar la confirmación manualmente al volver a basar en la parte superior del maestro, justo antes de fusionar PR (puede etiquetarlo/escribir un recordatorio en el mensaje de confirmación para resolver el conflicto).
Pero en mi opinión, cambiaría la base de la rama de funciones encima de la maestra cuando la revisión estuviera disponible. Esto es lo mismo que incorporar cualquier cambio desde el maestro (incluidas otras ramas de funciones fusionadas recientemente). Por lo tanto, no le preocupa que su sucursal esté desactualizada. Depende de lo que le guste manejar a su equipo: eliminar revisiones fusionadas o cambiar la base con frecuencia.
Respuesta2
Si realmente necesita la corrección de errores en su rama de funciones, combine la rama de corrección de errores. La charla sobre bisect/rollback/lo que sea que fuera FUD: bisect, en mi experiencia, maneja muy bien historiales de fusión complicados. El modelo propuesto en esa publicación crea problemas artificiales (como el que usted pregunta) y, literalmente, su único beneficio es un limpiador.mirandohistoria. Usamos este modelo durante un par de años antes de darnos cuenta del beneficio de no realizar cambios de base. Rebaseo cuando necesito limpiar mi propio historial (aplastar confirmaciones, cambiar mensajes de confirmación, etc.), pero eso no afecta a nadie más en sentido posterior (como si estuviera trabajando en la rama solo).