No quiero terminar con 82 feature branches hanging around, por lo que me pregunto cuáles son los posibles inconvenientes de simplemente eliminar la rama de función tan pronto como la fusiono con la maestra.¿Cuándo es el momento adecuado para eliminar una rama de función git?
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
Cualquier problema aquí?
Borrar después de la fusión es la forma habitual. Esta es la razón por la cual git branch -d comprueba para asegurarse de que la rama se combina completamente 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 registro histórico.
En cualquier caso, tiene la opción de etiquetar el encabezado de la rama antes de eliminarlo. Una etiqueta es como una rama en el sentido de que es un puntero a una confirmación, excepto por algunas diferencias menores: 1) la porcelana generalmente no muestra etiquetas en comandos exploratorios como git show-branch o tab-auto en el proceso de compra, 2) verificar uno lo coloca en un HEAD 3 separado (sin ref) puede dejar un "tagging message", que hace que la etiqueta se guarde como un objeto en el almacén de objetos como un commit.
De esta forma se conserva la historia, y si alguna vez necesitas corregir un error, te recomendamos simplemente crear una nueva rama de master para la corrección.
Verificar una etiqueta establece HEAD, pero no crea automáticamente una rama. Una CABEZA en un compromiso sin una rama es lo que lo separa. – Binarian
Tienes razón, establece HEAD en una identificación de confirmación en lugar de una referencia. Esa parte de mi OP es incorrecta. Debería actualizarlo. – masonk
Creo que es el flujo de trabajo típico (borrar después de combinación)
EDITAR Así, en lugar de unir, al menos para las sucursales de vida corta, creo que la idea es rebasar ellos en el maestro. luego terminas con un historial de cambio lineal, y toda la rama se convierte en parte del tronco principal. en este caso, tiene todos los cambios allí, por lo que claramente no necesita una copia.
Entonces realmente no tiene sentido mantener la rama, ¿verdad? – bstpierre
Recomiendo evitar "rebase". Rebase es generalmente dañino, solo útil en algunos casos. –
Rebasing es un flujo de trabajo perfectamente razonable para sus sucursales locales y privadas. Es muy común mantenerse sincronizado con el trabajo en sentido ascendente, por ejemplo, mediante el rebasamiento ("rebasing * down *"). Es mucho menos común, y generalmente nocivo, reubicar *. la respuesta del segundo no tiene sentido, porque si está modificando o fusionándose en cambios ascendentes, de todos modos tiene que empujar esas cosas "hacia arriba". Incluso en su sucursal local, tendrá que combinar su función para dominarla en algún momento. La ventaja de permanecer re-basado en sus características es que esta fusión se convierte en un avance rápido. – masonk
me ocurren dos razones por las que puede que desee tener una rama de la característica por un poco:
En la práctica, la mayoría de las veces eliminar después de la fusión está bien.
Lo elimino después de la fusión, pero siempre hago un git merge --no-ff, para evitar el reenvío rápido para que el historial de ramas sea visible en el gráfico. Me gustaría tener la historia de donde la rama de la característica se apartó de la rama de desarrollo y donde se unió de nuevo:
Esto está tomado de A successful Git branching model por Vincent Driessen, un muy buen flujo de trabajo para usar con git cual aplicar para la mayoría de mis proyectos.
Esta es otra buena manera de preservar el historial, ya que puede seleccionar las confirmaciones a las que se puede acceder desde la función, pero no desde el maestro: rev^1..rev^2. El inconveniente es que estropea cualquier rebase que desee hacer desde su rama principal (por ejemplo, si desea mantener el maestro rebasado en el control remoto aguas arriba, que es muy común). – masonk
No tuve ese problema. Nuestro equipo se sincroniza a través de github, y generalmente no necesito volver a establecer la base, pero no creo que sea un inconveniente aquí. Incluso si rebase su rama de desarrollo y características, la bifurcación permanece visible en el gráfico, y lo que importa es qué hay en la rama de características en relación con el desarrollo, no la confirmación en la que se partió originalmente cuando creó esa rama. – lkraider
@Ikraider, gracias por el recordatorio. Vi ese artículo cuando estaba aprendiendo git, ahora tiene más sentido para mí. Rebase mis ramas de características, pero me 'fusiono --no-ff' de nuevo en el maestro porque, como dices, puedes ver el historial. – bstpierre
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
yo diría que no hay problemas, porque si realmente los necesita siempre se puede resucitar a la rama se elimine más tarde. – slebetman
@slebetman Por lo que yo sé, una sucursal eliminada no puede resucitar. Sin embargo, si la rama se fusionó completamente en el maestro antes de eliminarla, no debería haber ninguna necesidad de la rama más. – Simeon
@Simeon Sí, puedes. Git nunca borra las confirmaciones, por lo que cuando borras tu sucursal solo estás eliminando su nombre. Para resucitar una sucursal eliminada solo necesita recordar lo último que se comprometió con esa sucursal y puede buscar 'git reflog' para ella. Luego, revise el hash – slebetman