Cuándo eliminar las twigs de control de versiones?

Actualmente estamos jugando con Git, uno de nuestros desarrolladores quiere eliminar las antiguas sucursales de nuestro repository. El motivo de esta request es 'mantenimiento de la casa' .

Soy de un background SVN y no soy un experto en Git pero, según mi experiencia con SVN, nunca eliminas una twig; fue una regla general desde el primer día.

No se gana nada borrando una twig en SVN porque su tamaño es relativamente pequeño y puede contener información importante de compromiso / fusión que se perdería por completo si se eliminara. Y, desde una perspectiva de mantenimiento de la casa, si esta twig es demasiado horrible para mirar, siempre se puede mover a otra location que esté fuera del path del flujo de trabajo normal.

¿Alguien tiene alguna razón concreta para eliminar sucursales de un moderno sistema de control de versiones?

De acuerdo con la respuesta aceptada en la pregunta SO, "Git – Cuándo eliminar sucursales ":

 You can safely remove a branch with git branch -d yourbranch. If it contains unmerged changes (ie, you would lose commits by deleting the branch), git will tell you and won't delete it. 

Sin embargo, otro autor continúa diciendo:

  the disadvantage of deleting branches is that you will break any hyperlinks to those branches on GitHub. 

Uno de los mayores arguments que he encontrado que habla de la desventaja de eliminar sucursales se trata en el artículo titulado " Por qué no me gustan las twigs de características ":

  If feature branches are deleted once they are merged into master, where do bug fixes go? On a new feature branch or on master? There will no longer be an easy way to find a list of the commits that went into a feature. 

El artículo Fundamentos de Git: Limpiar el exceso de sucursales , muestra cómo puede automatizar la eliminación de sucursales y hacer que sea un process más rápido, si elige hacerlo.

¡Por favor hazme saber si tienes preguntas!

Esta respuesta es en reference a Subversion.

No tengo ningún reparo en eliminar twigs y tags obsoletas en Subversion. Mantiene limpios los directorys /tags y /branches . En lugar de cientos de twigs y tags, solo pueden aparecer un par de docenas.

Si una twig ya no se usa para el desarrollo activo, y nadie está interesado en el código, ¿por qué no eliminarlo? Si ha labeldo una revisión de su código que ningún cliente está utilizando, y ningún desarrollador ya no hace reference, ¿por qué no eliminarlo?

Por lo general, tengo algún tipo de base de time para las sucursales. No se hizo trabajo en ellos por un año? Ellos son candidatos para su eliminación. Si los desarrolladores ya no están interesados ​​en el código, sale.

En Subversion, nada se borra permanentemente. Siempre puedes recuperarlo:

Digamos que borré la label a la versión 1.6 de nuestro código. De repente, un ejército de auditores aparece exigiendo examinar esa versión particular del código. Puedo correr:

 $ svn log -q -v http://server/repo/tags | less 

Y, encuentre cuando borré esa label:

 ------------------------------------------------------------------------ r76229 | smith | 2011-09-01 11:26:47 -0400 Changed paths: D /tags/1.6 

La label 1.6 fue eliminada en la revisión 76229, entonces sé que la label estaba en la revisión 76228 de mi repository. Puedo restaurar esa label:

 $ svn cp -r76228 http://server/repo/tags/1.6@76228 http://server/repos/tags/1.6 

Si solo quiero ver este código, podría verificarlo sin recuperar la label:

 $ svn co -r76228 http://server/repo/tags/1.6@76228 

Ahora los auditores pueden ponerse a trabajar y molestar a los desarrolladores y dejarme en pedazos.

Las twigs en Git (generalmente hablando) no importan después de que se hayan fusionado. Solo son útiles si apuntan a confirmaciones únicas no accesibles por otros medios.

Git incluso proporciona una git branch --merged que está documentada como

 --merged is used to find all branches which can be safely deleted, since those branches are fully contained by HEAD.