remota - git squash

¿Por qué vuelve a aparecer el mismo conflicto cuando uso git rebase?

Question

He leído preguntas relevantes sobre git merge y git rebase en SO, pero todavía no puedo entender completamente lo que está pasando bajo el capó.

Aquí está nuestra situación de ramificación:

MASTER------------------------
/ /
/ /----Feature B---
/ /
/-----Feature A----------/---Feature A+B

Tenemos 2 ramas de características que provienen del maestro en un momento diferente, ahora queremos combinar las 2 ramas. Queremos seguir la first rebase then merge práctica, pero cuando cambiamos la Característica A a la Característica B, tenemos conflictos. Eso se espera, porque ambas características (y maestras) tienen cambios en las mismas áreas. Pero lo extraño es que el mismo conflicto sigue reapareciendo después de git rebase --continue . Esto nos vuelve locos, por lo que terminamos abortando la rebase y usamos git merge . Resulta que los conflictos son realmente fáciles de resolver.

Mi pregunta es doble:

1. ¿Es git rebase adecuado para nuestra situación? ¿O es el rebase solo bueno para tirar en pocos (1 o 2) cambios?
2. ¿Qué está sucediendo bajo el capó que hace que el mismo conflicto reaparezca una y otra vez? Mi entendimiento es rebase resolver los conflictos uno por uno, pero ¿comparando con qué compromiso?

Publicaciones Relavant en SO:

• ¿Por qué tengo que resolver el mismo conflicto una y otra vez?
• ¿Cómo prevenir muchos conflictos de git cuando git rebasa muchos de los compromisos? /
• git rebase resolver conflictos una y otra vez?

Answer 1

¿Rebase es adecuado para su situación?

Basado en el hecho de que la Feature A y la Feature B parecen ser ramas compartidas , yo diría que no .

Rebasar es una forma de fusionar ramas sin tener que combinar confirmaciones (es decir, confirmaciones que tienen dos o más padres) para que aparezca como un historial lineal. Es mejor utilizarlo para combinar sucursales locales , es decir, las sucursales que solo existen en su repositorio local y no se han publicado para otras personas. ¿Por qué? Por al menos dos razones:

1. La modificación de la base cambia los ID de confirmación (es decir, los hashes SHA-1 de sus metadatos). Esto significa que una vez que presiona los compromisos rebasados ​​a la rama compartida , aparecerán como compromisos completamente nuevos para cualquiera que los busque en su repositorio local, incluso si aún contienen los mismos cambios. Ahora, si alguien ha agregado nuevas confirmaciones sobre las antiguas mientras tanto, tendrá que moverlas. Esto crea una confusión innecesaria.

2. Cuando combina las sucursales públicas, a menudo desea que esas combinaciones se combinen para poder hacer un seguimiento de cómo se mueven las comprometidas entre las sucursales. Esa información se pierde con el rebasado.

¿Qué está pasando bajo el capó?

Sólo una fusión regular. La diferencia es que git rebase combina una confirmación a la vez sobre la anterior a partir de la matriz común. git merge combina dos compromisos, con su conjunto completo de cambios, como una sola operación, por lo que solo tiene que resolver los conflictos una vez.

Actualización: Resolviendo conflictos recurrentes.

Como @Jubobs señaló en los comentarios, Git tiene una solución automatizada para resolver conflictos que ocurren varias veces: git rerere , o " reutilizar resolución registrada ".

Después de habilitar la referencia en su archivo de configuración ( rerere.enabled true ) cada vez que se produce un conflicto de combinación, Git registrará el estado de los archivos en conflicto antes y después de combinarlos. La próxima vez que ocurra el mismo conflicto, un conflicto que involucra exactamente las mismas líneas en ambos lados de la combinación, Git aplicará automáticamente la misma resolución que había registrado anteriormente. También le informará al respecto en la salida de combinación:

CONFLICTO (contenido): fusionar conflicto en ''somefile''
Resuelto ''somefile'' usando la resolución anterior.

Aquí puede encontrar más detalles sobre cómo lidiar con los conflictos usando git rerere .