¿Cuándo es el momento adecuado para eliminar una twig de características de git?

No quiero terminar con 82 twigs de características por ahí , así que me pregunto cuáles son los posibles inconvenientes de simplemente eliminar la twig de características tan pronto como la fusione con la maestra.

Flujo de trabajo:

git co -b feat-xyz hack hack git ci hack some more git ci git co master git merge feat-xyz smoke test git br -d feat-xyz 

¿Algún problema aquí?

Eliminar después de la fusión es la forma habitual. Esta es la razón por la cual git branch -d comtesting para asegurarse de que la twig esté completamente fusionada antes de que se elimine.

Hay algunas razones por las que se me ocurre mantener una sucursal: es posible que desee conservarla en caso de que los errores vuelvan a aparecer una vez que llegue a producción, o puede que desee un logging histórico.

En cualquier caso, tiene la opción de labelr el encabezado de la twig antes de eliminarlo. Una label es como una twig en el sentido de que es un puntero a una confirmación, excepto por algunas diferencias menores: 1) la porcelana generalmente no muestra tags en commands exploratorios como git show-branch o tab-auto en el process de compra, 2) Al marcar uno, se coloca un HEAD 3 (que no es de reference) separado. Puede dejar un " post de labeldo ", que hace que la label se guarde como un object en el almacén de objects como un compromiso.

De esta forma conservas la historia, y si alguna vez necesitas corregir un error, te recomiendo que crees una nueva twig de master para la corrección.

Lo elimino después de la fusión, pero siempre hago una git merge --no-ff , para evitar el reenvío rápido para que el historial de la twig sea visible en el gráfico. Me gusta tener el historial de dónde partió la twig de características de la twig de desarrollo y dónde se unió:

Fusionando con o sin avance rápido

Esto es tomado de un exitoso model de ramificación de Git por Vincent Driessen, un muy buen flujo de trabajo para usar con git que aplico para la mayoría de mis proyectos.

Puedo pensar en dos razones por las que es posible que desee mantener una twig de características por un time:

  • Existe la posibilidad de que le devuelvan el impulso para que trabaje más río arriba.
  • Otros desarrolladores posiblemente quieran esa característica sin querer todo lo demás en master.

En la práctica, la mayoría de las veces eliminar después de la fusión está bien.

El flujo de trabajo típico será

  // Create new branch $ git checkout -b myfeature // and then do some changes and commit them // Switch to master branch $ git checkout master // Merge myfeature to master. --no-ff will always keep branch information. $ git merge --no-ff myfeature // Delete myfeature branch $ git branch -d myfeature // Push the changes $ git push origin master 

creo que es el flujo de trabajo típico (eliminar después de la fusión)

EDITAR Entonces, en lugar de fusionar, al less para twigs de vida corta, creo que la idea es volver a establecerlas en el maestro. luego terminas con un historial de cambio lineal, y toda la twig se convierte en parte del tronco principal. en este caso, tiene todos los cambios allí, por lo que claramente no necesita una copy.