¿Cómo podrían los commits estar en una twig dos veces?

Tengo la siguiente historia de Git:

DEABCABC (feature2) / *-DE (feature1) / *-F (develop) 

No tengo idea de cómo A, B y C terminaron en feature2 dos veces. He estado networkingefiniendo feature2 dentro y fuera de feature1 usando git rebase feature1 y git rebase --onto develop feature1 . He rectificado la situación seleccionando A, B y C en una nueva twig de desarrollo, pero: ¿cómo pudo haber sucedido esto? Estoy perplejo.


Editar

No tengo idea de lo que Github está haciendo aquí, pero ahora Git está diciendo:

 Your branch and 'origin/feature2-fresh' have diverged, and have 113 and 100 different commit(s) each, respectively. 

¿Entonces parece que es culpa de Github?

Esto es lo que sucedió:

  • Así que feature2 por feature2 .
  • Volví a feature2 en develop .
  • Empujé feature2 , luego me di count de que había más trabajo por hacer, también lo hizo la danza de rebase nuevamente ( feature1 era necesaria para ejecutar feature2 ).

Ahora, los SHA-1 de todos los commits exclusivos de feature2 son diferentes a los commits correspondientes en origin/feature2 .
Sin darme count, hago un pull . Git vuelve a fusionar obedientemente todos los commits, porque tienen SHA diferentes. La moraleja de la historia es:

No rebase una twig empujada.

Una posibilidad:
La confirmación duplicada puede ser un indicador de git cherry-pick (consulte " git – ¿qué es cherry-pick? " Y su problema de confirmación duplicado ).

Si A y B fueron seleccionados en cualquier momento después de la rebase, podrían agregarse a feature2 aunque esa twig ya contenga A y B (con SHA1 diferente).

Si A y B fueron elegidos cuidadosamente antes de la rebase, entonces A y B no deberían haberse repetido (de la página de git rebase )

Si la twig ascendente ya contiene un cambio que ha realizado (por ejemplo, porque envió por correo un parche que se aplicó en sentido ascendente), se omitirá esa confirmación.