2011-04-26 31 views
5

De alguna manera tengo algunos commits duplicados en una rama, cada uno con los mismos cambios. Es una sucursal pública, fusionada de varias sucursales por varios usuarios. Necesito actualizar periódicamente esta rama en la rama principal de otro repositorio, y estos duplicados lo hacen torpe.git: eliminar las confirmaciones duplicadas de la rama pública

¿Hay alguna manera de eliminar estos y enviarlos al repositorio público sin que sea complicado para otros usuarios que trabajan desde la sucursal?

+1

Suponiendo que considere la recuperación de la reescritura del historial (es decir, la rebase de todo desde la rama pública original a la nueva) como complicada, no, no hay forma de hacerlo. La eliminación de confirmaciones está reescribiendo el historial. – Cascabel

+2

¿Estás seguro de que tienes commits duplicados _en la misma rama_? A mi parecer, la única forma real de que esto pueda suceder es primero reajustando y luego fusionando la rama previamente rebasada. Sin embargo, la fusión no será rápida, y las confirmaciones fusionadas serán técnicamente 'desde la fusión' no 'desde la sucursal' (es decir, cuando se sigan a los primeros padres solamente, un registro no mostrará las confirmaciones). ¿Tiene sentido? – sehe

+0

Creo que sehe tiene razón, tienes que asegurarte de que estén en la misma rama. "rebase -i" debería aclarar eso momentáneamente, ya que el OP podrá ver de inmediato si el problema realmente existe como se describe –

Respuesta

0

Use git filter-branch para reescribir el historial. He aquí una buena introducción de GitHub:

http://help.github.com/removing-sensitive-data/

+0

Una parte clave de la pregunta del OP es "sin complicarlo para otros usuarios", y eso es esencialmente imposible. Siempre tendrán que tomar algunas medidas para recuperarse de la reescritura de la historia. – Cascabel

4

filter-branch no es necesario en este caso en mi humilde opinión, y como se mencionó Jefromi sin hacer la vida un poco complicado para todos los demás es imposible. Primera regla de Git: no reescribas el historial publicado.

Si realmente desea limpiar la rama que se ha estropeado, debe volver a establecer la base local, reorganizar las confirmaciones y forzarla a la línea principal si es necesario.

con el fin de hacer eso (imaginemos que la rama se comprueba a nivel local y el último estado bueno conocido después de lo cual se han comenzado a obtener los duplicados es hace 20 commit)

git checkout yourPublicBranch 
git rebase -i HEAD~20 

Esto fuego de la editor en el que podrá gestionar los commits. Luego deberá guardar el archivo y salir para rebase para comenzar a trabajar. Eso puede conducir a conflictos.

+0

Sé cómo hacer un reajuste interactivo para deshacerme de las confirmaciones. Puedo forzarlo al repositorio público si es necesario. ¿Qué deben hacer los usuarios después de eso para sincronizarse? Si no han hecho ningún cambio en sus copias locales de la rama que conozco (?), Pueden simplemente sacar la nueva rama y estar bien. Pero si se hacen sus propios cambios locales mientras tanto? Gracias. – michael

+1

Debe notificarles que el historial se ha reescrito para esta rama. Luego tienen que: 1. "git fetch remoteName" - esto actualizará las ramas de seguimiento remoto y les notificará sobre la actualización forzada en la rama de interés 2.si no tienen cambios locales en esta rama, simplemente pueden extraer y se sobrescribirán. Si tienen cambios en el Brach local que está rastreando este reescrito, pueden hacer "git pull - rebase", por lo que sus cambios locales se volverán a establecer en la parte superior del nuevo historial. Si tienen otras ramas que se generaron a partir de esta pública, tendrán que volver a basarlas también. –

+0

Genial, gracias. No me di cuenta de que podría ser tan simple como hacer "git pull --rebase". Cruzaron los dedos que se encargarán de eso. – michael

Cuestiones relacionadas