2011-08-12 15 views
5

No estoy contento con el título pero creo que superplicó mi explicación y al final es tan simple como la anterior.Eliminar fusiones incorrectas del repositorio

Estamos utilizando un modelo de bifurcación con un repositorio de origen central, una rama de "desarrollo", con sucursales de esta rama.

que había desarrollado un conjunto local de los cambios de la rama desarrollar, algo así como:

develop (A)- (D1) - (D2) 
     \ - (F1) - (F2) - (F3) - (F4) 

En este punto me deslicé en mi GUI Git y, en lugar de empujar mi rama de funcionalidad como una rama remota a origen, de alguna manera lo empujé de regreso a origen/desarrollo. Entonces, ahora teníamos:

develop (A)- (D1) - (D2) -  -  (M1) 
     \ - (F1) - (F2) - (F3) - (F4)/

Que aún no queríamos. Como solo había yo y otro desarrollador en este día en particular, inicié sesión en el host de origen y manipulé el encabezado de desarrollo en la confirmación D2 y mi rama de funciones volvió a F4. Le pedí a mi colega que no tire hasta que hice esto, y pensé que todo estaba bien.

(en realidad, cloné el repositorio de origen, hice que la cabeza cambiara localmente y luego los empujé hacia atrás. No recuerdo los comandos exactos, pero el resultado fue el repositorio según lo deseado, en la medida de lo posible Podría ver).

Lo que había olvidado es que nuestro sistema de integración continua hacía tiradas regulares y conseguíamos una copia de las cabezas fusionadas. Una semana más tarde noté algunos commits por parte de cruisecontrol en el host de origen y tuve un mal presentimiento. Efectivamente, se trataba de fusionar el origen desarrollar cabeza en su repositorio local "rama fusionada".

Así que ahora estamos en una situación algo como esto:

climatizador repo:

 (from origin/develop)   (C1) - (C2) - (C3) 
develop (A)- (D1) - (D2) -  -  (M1) \ (M2) \ (M3) 
     \ - (F1) - (F2) - (F3) - (F4)/

repo Origen:

develop (A)- (D1) - (D2) - (C1) - (C2) - (C3) 
     \ - (F1) - (F2) - (F3) - (F4) 

donde C1 y C2 son commits hacen en el repositorio de origen por nosotros los desarrolladores que tienen el repo "corregido" (es decir, después de las manipulaciones de mi cabeza para deshacer mi error inicial), y M2 y M3 son los compromisos de fusión que el repo de crucero ahora tenía que hacer.

Ahora hice algo realmente estúpido. Me "empujaron git" en el repositorio fuente de cruisecontrol. Así que nuestro repos de "origen" ahora tiene la fusión M1 y el M2 y M3 intermedios se fusionan.

Una vez más he conseguido que mis colegas no tiren por un tiempo. Sin embargo, mi git-foo no es lo suficientemente fuerte para desenredar los commit de Mx y Cx entre sí en el repositorio de origen y restaurar las cosas a su estado original.

I que tengo que hacer algo inteligente con CABEZA^(x) y HEAD ~ (y), pero esta es una situación difícil de explicar de manera sucinta y por lo tanto más difícil de Google para.

Todos los consejos fueron bienvenidos; Tengo una copia de respaldo nocturna del repositorio en ejecución y probablemente pueda restaurarlo y que todos vuelvan a enviar sus compromisos a partir de hoy, pero me gustaría saber si este tipo de desenredo de ramas es posible en absoluto.

Creo que debería poder terminar con el repositorio de origen como en el diagrama de origen anterior, y el repositorio cruisecontrol borrado y clonado, y la serie M de confirmaciones lista para ser recogida de basura en el repositorio de origen.

Gracias!

+0

¿No pudo suspender el CI, clonar el repositorio de CI, restablecerlo en un buen estado y forzarlo a retroceder? ¿Como lo hiciste por el origen? – VonC

+0

¿Cómo hicieron ustedes C1 y C2 cuando no tenían M1? – Andy

+0

Me ayudaría si muestra el estado final deseado porque no estoy seguro de dónde quiere terminar. –

Respuesta

2

todos los envíos en git con el mismo hash son idénticos (y también lo es que hay historia), por lo que debe ser capaz de utilizar los mismos comandos, tanto en su origen y su repositorio CI (teniendo en cuenta que develop está desprotegido:

# on the current branch: 
git reset --hard C3 
# on your feature branch: 
git branch -f feature F4 

git push no debe forzar pulsación por defecto, y que no declaró que en su pregunta donde ocurrió el CI -> origin empuje, así que estoy asumiendo que era un empuje de avance rápido (por defecto)

de el futuro Recomiendo su repositorio de CI para hacer un git fetch + git reset --hard origin/develp, a menos que desee fusionar sus sucursales (posiblemente con confirmaciones solo existentes en el repositorio de CI)

+0

Esto hizo el truco. Me tomó un momento mirar fijamente la salida de gitg para "verla", pero como solo la serie M de confirmaciones tiene múltiples padres (por ejemplo, la M (n-1) y la Cn), restablecer la cabeza a C3 da la historia como se desea. Creo que mi explicación puede ser un poco complicada ... Gracias a todos. –

Cuestiones relacionadas