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.
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ó:
feature2 por feature2 . feature2 en develop . 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:
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.