¿Qué hacer con las twigs de git experimentales no fusionadas?

¿Cuáles son las mejores prácticas actuales con las twigs de git que se han creado para probar una solución a un error y que no se han fusionado porque el process de revisión muestra que están equivocadas o que hay mejores soluciones para el problema?

Un ejemplo. Proyecto fizzbuzz tiene un informe de error que informa un locking en los campos vacíos.

  • Creo una nueva twig handle-empty-fields y hago dos commits para esa twig, "resolviendo" el problema.
  • Luego envío esa twig al administrador del proyecto fizzbuzz, vinculándola al informe de errores.
  • Alguien encuentra un error en mi solución, escribe otro parche y ese parche es aceptado.

Ahora el código en el handle-empty-fields mi código es inútil: no es correcto y no se puede aplicar más al código, pero se ha hecho reference en ese informe de errores.

¿Que debería hacer? Mantenga la twig? Pronto terminaré con docenas de twigs abandonadas y git no tiene forma de marcar una twig como abandonada o cerrada. Quitar la twig? Pero luego las personas que miren ese informe de errores lo encontrarán y obtendrán el 404.

A menudo se sugiere a las personas no volver a establecer la base de sus repositorys porque eso causará problemas a otros desarrolladores, especialmente a los desarrolladores descendentes. ¿Cuáles son las sugerencias para las twigs de function o corrección de errores?

Actualización : parece que github nunca elimina las confirmaciones contenidas en las requestes de extracción. Por lo tanto, si envía los cambios y los convierte en una request de extracción, puede eliminar la twig más adelante sin perder ninguno de sus cambios. Bueno, mientras github todavía está trabajando;).

git update-ref refs/Attic/handle-empty-fields refs/heads/handle-empty-fields

Como alternativa a la preservación de twigs muertas en las tags, puede usar un espacio de nombres de reference separado. Lo bueno es que la list de tags se mantiene despejada. Una desventaja es pasar de la porcelana al nivel de plomería de git.

La forma en que lo hago es darle una label. Usa una label completa y dale un nombre descriptivo. Luego puede eliminar la twig, para que no aparezca en sus listdos de sucursales, pero debido a que está labelda, la twig aún se puede volver a crear al verificar la twig. Todos los commits en la label seguirán estando disponibles, y no perderás ningún commit en un git gc Algo así, quizás:

 git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX" 

Creo que esto dependerá de las circunstancias exactas. Soluciones posibles:

  • Agregue un comentario al informe de error, que indica que la twig mencionada resultó ser inútil y se eliminó. Si crees que la twig tiene algún valor, describe brevemente lo que hiciste. De esta forma, las personas obtienen la información necesaria aunque la sucursal se haya ido.

  • Mantenga la twig, pero de alguna manera cambie el nombre para marcarla como "abandonada". Agregue un comentario al informe de errores para indicar esto (y cambie el enlace a la twig). Por ejemplo, podría tener alguna convención como el prefijo "OLD-" a los nombres de las sucursales.

  • Etiquete la twig, luego bórrela (y vuelva a mencionar esto en la input bug db). De esta forma, se puede eliminar la twig, pero las confirmaciones aún son accesibles a través de la label. Tenga en count que git ofrece espacios de nombre simples para tags (y twigs); puede include un '/' en el nombre. Puede aceptar una convención, como usar tags en "oldbranch /". ( Adaptado de la respuesta de Abizern )

  • Una vez que la twig se ha fusionado, puede mencionar / vincular la confirmación de fusión en el informe de errores. Entonces, la twig probablemente sea less interesante, porque está contenida en la combinación de fusión.

En general, es posible que desee adoptar una convención de nomenclatura especial para las twigs de corrección de errores.

En mi repository git (personal), por cada error que encuentro, primero abro un error en el DB de errores. Si luego trabajo en ello, creo una twig cuyo nombre termina con la identificación del error (por ejemplo, "opencrash-342", "handle_empty_file-663"). De esta forma, la relación entre bug DB y branches es obvia.

Además, si la list de sucursales es demasiado larga, siempre puede filtrar por el ID adjunto (por ejemplo, hacer una list de errores cerrados, y algunos pequeños guiones para filtrarlos de la salida de "git log", etc.).

Este es solo mi punto de vista, pero supongo que puedes soltar cualquier twig que no tenga un código útil. En el peor de los casos, si alguien, algún día mirará el informe de errores y descubrirá que el enlace a la corrección de errores rechazados está roto … bueno, no creo que parezca un gran problema para nadie.