73 votos

Cuando es el momento adecuado para eliminar un git branch característica?

No quiero terminar con 82 característica de las ramas que cuelgan alrededor, así que me pregunto qué posibles inconvenientes son simplemente la eliminación de la rama de característica tan pronto como me fusione a maestro.

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í?

82voto

lkraider Puntos 977

Puedo eliminar después de combinar, pero yo siempre hago una git merge --no-ff, para evitar el avance rápido para que la rama de la historia es visible en la gráfica. Me gusta la historia de donde la rama se partió de la rama de desarrollo y donde se unió a la espalda:

Merging with or without fast-forwards

Esto es tomado de Una exitosa Git branching modelo de Vincent Driessen, un muy buen flujo de trabajo para utilizar con git que puedo aplicar para la mayoría de mis proyectos.

50voto

masonk Puntos 1572

Eliminar después de la combinación de la forma habitual. Esta es la razón por la git branch-d comprobaciones para asegurarse de que la rama es totalmente fusionada antes de eliminarla.

Hay un par de razones por las que no puedo pensar en mantener una sucursal en torno a: usted podría querer aferrarse a ella en caso de tener errores de regresar una vez que golpea la producción, o usted puede ser que desee un registro histórico.

En cualquier caso, usted tiene la opción de etiquetado de la cabeza de la rama antes de eliminarlo. Una etiqueta es como una rama en la que es un puntero a un commit, excepto por algunas diferencias de menor importancia: 1) la porcelana, en general, no muestran las etiquetas en la exploratorio de comandos como git show-sucursal o de la ficha de auto completo en caja, 2) la comprobación de que uno no se pone en la HEAD (que será en un desprendimiento de la HEAD), y 3), usted puede dejar una "etiqueta" de la nota en la parte superior de la nota en la confirmación de que los puntos en.

De esta manera preservar la historia, y si alguna vez necesitan de corrección del error, te recomiendo la creación de una nueva rama de la maestra por la corrección.

6voto

Karl Bielefeldt Puntos 15469

Se me ocurren dos razones por las que es posible que desee mantener una rama de la característica de todo un poco:

  • Existe una posibilidad de que sea pateado de nuevo a usted para obtener más trabajo por parte de aguas arriba.
  • Otros desarrolladores, posiblemente, queriendo que sin querer todo lo demás en el maestro.

En la práctica, la mayoría de el tiempo de eliminación después de la mezcla está bien.

5voto

Fizer Khan Puntos 4128

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

1voto

second Puntos 11641

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

EDITAR Así, en lugar de combinar, al menos para la corta de las ramas, creo que la idea es de reajuste a la maestra. a continuación, puedes terminar con un cambio lineal de la historia, y toda la rama se convierte en parte del tronco principal. en este caso, usted tiene todos los cambios de allí, por lo que claramente no necesita una copia.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X