2011-09-26 7 views
11

Nuestro git repo tiene una gran cantidad de archivos grandes en su historial que ya no se necesitan. Quiero eliminarlos utilizando la técnica de filtro de la rama explica en Pro Git:Reasignación de todos al historial de git modificado después de la rama de filtro

http://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery

voy a continuación, utilizar git push --force all a enviar esto a nuestro repositorio compartido, como se explica aquí:

Update a development team with rewritten Git repo history, removing big files

PERO. Pro Git dice que necesitaré tener a todos rebaseados ya que estoy cambiando la historia. Solo usamos con moderación la rebase, generalmente solo como una forma alternativa de fusionar. Puedo hacer que todos vuelvan a clonarse, pero ese es un último recurso; varios desarrolladores tienen sucursales locales con cambios que les gustaría mantener.

Entonces, ¿qué harán exactamente todos en nuestros repositorios locales para volver a establecer una base en el repositorio compartido recientemente cambiado? ¿Y tenemos que hacerlo una vez por cada rama de seguimiento? Nuestro repositorio se conoce como origen y la rama principal es maestra, si quieres dar paso a paso (y me encantaría que lo hicieras).

Respuesta

3

Aquí hay una opción.

  • Crear tu amo porcentualizada en una rama llamada rebased_master (en lugar del original master).
  • Debería empujar esa rama y hacer que todos sus desarrolladores la reduzcan y vuelvan a establecer sus sucursales locales en rebased_master. Si los vuelven a relacionar con la confirmación equivalente de antes de la rebase, y no tienen ningún cambio en los archivos que está eliminando, todos deberían estar bien.
  • vez que todos hayan trasladado sus ramas dev a rebased_master, puede eliminar el original master y moverebased_master a master

nota: no he probado esto, así que asegúrese de que tiene una copia de su cesión temporal a restaurar en caso de que algo salga mal

+1

Esto suena bien - ¡Lo aceptaré en la mañana después de que realmente funcione! –

+3

Entonces? ¿Funciona? Esa mañana ha pasado, supongo ... – marton78

14

La clave es que cada desarrollador individual no pierda su referencia original a master hasta después de haber hecho su rebase. Para ello, tienen que hacer un fetch (no un tirón) después del empuje forzado, a continuación, para cada rama local, hacer:

git rebase --onto origin/master master <local_branch> 

Cuando se hace eso, entonces se puede comprobación de su master y actualizarla :

git pull --force 
Cuestiones relacionadas