git pull –rebase falla con el conflicto, pero git push funciona

Ayer tuvimos esta situación muy extraña con git:

  1. Creamos una twig de características como siempre lo hacemos. Entonces, alguien trabajaría durante algunos días en esa twig de características.

  2. Mientras tanto, algo importante sucedió en la twig principal. Estos cambios también fueron necesarios por la twig de características.

  3. Por lo tanto, fusionamos la twig principal en la twig de características (sin rebase porque nuestras twigs de características usualmente se envían inmediatamente a remoto ya que necesitamos queueborar en una característica). Esta fusión solo se realizó localmente y aún no se envió a control remoto.

  4. El trabajo en la twig de características continuó

  5. Con la combinación de master + el trabajo continuo, la twig de características locales new_feature estaba ahora por delante de origin / new_feature por 40 commits

  6. Ahora queríamos enviar estas 40 confirmaciones a la twig de características remotas. Primero hacemos un git pull –rebase como siempre hacemos antes de presionar porque alguien más pudo haber enviado algunos commits antes que nosotros.

  7. Ahora experimentamos toneladas y toneladas de conflictos. Decidimos que no vale la pena arreglar 40 commits y hacer un git rebase –abort. Luego probamos un git pull –no-rebase. Obtenemos: "Ya está actualizado" – Extraño

  8. Dado que el estado de git no nos dice que nuestra sucursal local y la sucursal remota han divergido, probamos git push

  9. Inesperadamente, git push funcionó. Nos gustaría get un rechazado si tratamos de presionar a una sucursal remota que ha cambiado desde la última vez que tiramos. Entonces, obviamente, lo remoto no ha cambiado, pero Git Pull –rebase hizo algo extraño.

Entonces, lo extraño de esto es que

  1. git pull –rebase no devolvió inmediatamente "Ya está actualizado" y

  2. git pull –rebase informó una tonelada de conflictos en los que realmente ninguno debería salir (los conflictos informados no tenían nada que ver con lo que se trabajó en la twig de características)

¿Qué podría causar tal situación?

Desafortunadamente, una rebase después de una git merge provocará esto, a less que haya habilitado previamente git rerere. Ver git rebase después de la combinación anterior de git

Creo que obtendrías el resultado esperado incluso si hubieras habilitado la repetición o si hubieras resuelto todos los 40 conflictos. El problema es: ¡haces una rebase pero quieres comprometer una fusión! Al llamar a "git pull – rebase", git realizaría un "git rebase origin / featureXY" (asumiendo que su twig de function se llamara featureXY). Además, si no hay cambios en el origen, realice una rebase en su twig actual al estado de la twig de origen. Y git funciona como siempre cuando llevas a cabo una rebase en un commit de fusión. Resuelve cada fusión y crea una historia plana. Esto significa que cada compromiso del maestro que se fusionó previamente en la sucursal se aplicará en su sucursal. El resultado sería un historial directo sin ningún compromiso de fusión.

Conclusión: ¡Evita mezclar rebase y fusionar! En su flujo de trabajo, es inevitable impulsar una combinación directamente o no puede continuar utilizando pull-rebase.