¿Cuándo eliminar ramas en Git?

Lo que necesitas hacer es etiquetar cualquier cosa que liberes. Mantenga las ramas alrededor para cuando usted está desarrollando activamente.

Eliminar las ramas antiguas con

git branch -d branch_name

Elimínalos del servidor con

git push origin --delete branch_name

O la sintaxis antigua

git push origin :branch_name

Que se lee como "push nothing into branch_name at origin".

Dicho esto, mientras el DAG (grafo acíclico dirigido) pueda señalarlo, las confirmaciones estarán allí en la historia.

Google "git-flow" y eso puede dar un poco más información sobre la gestión de versiones, la ramificación y el etiquetado.

Dado que la pregunta tiene la etiqueta "github", también agregaría esto: específicamente en Github, si pull-request una rama y se fusiona (ya sea a través de la interfaz de usuario o fusionando la rama de la solicitud de extracción), no perderá los datos de la solicitud de extracción (incluidos los comentarios), incluso si elimina la rama.

Una consecuencia de esto: Si incorpora pull requests como parte de su flujo de trabajo (que se combina dulcemente con las revisiones de código), puede eliminar ramas de forma segura tan pronto como se fusionan. Esto es tan común que recientemente Github agregó una característica (dulce) que hace aparecer un botón "eliminar rama" justo después de fusionar una solicitud de extracción.

Pero vale la pena notar que cada grupo debe adoptar el flujo de trabajo que más le convenga (y puede o no conducir a la eliminación de dichas ramas). Mi equipo de trabajo actual, por ejemplo, poda todas las ramas que no están relacionadas con el maestro o el despliegue (por ejemplo, producción, puesta en escena, etc.).) tan pronto como sus pull requests se fusionan, y seguimos tener un seguimiento completo de cómo los commits relacionados formaron cada mejora incremental de cada producto.

Por supuesto, ninguna gestión del historial (pull requests o de otra manera) reemplaza el etiquetado adecuado de las versiones (que preferiblemente automatiza con la misma herramienta/script que implementa/empaqueta una versión), por lo que siempre puede cambiar rápidamente a lo que sea que sus usuarios estén encendidos en un momento dado. El etiquetado también es la clave para resolver su problema original: si establece que cualquier rama se fusionó con el " trabajo" las ramas pueden y deben ser eliminadas, y que cualquiera que se fusiona con una etiqueta de versión, "producción", etc. si no, siempre tendrás las revisiones vivas hasta que se integren en una versión futura.

Añadiría que la desventaja de eliminar ramas es que romperás cualquier hipervínculo a esas ramas en GitHub (esta pregunta está etiquetada con github). Obtendrás un error 404 Not Found para esos enlaces. Esta es la razón por la que cambio mis enlaces para que apunten a una confirmación o etiqueta después de eliminar una rama en GitHub.

Debido a que algunos enlaces no se pueden cambiar, como en el correo electrónico, ahora evito el hipervínculo a las ramas de GitHub por completo y enlazo a una confirmación o etiqueta desde el primer día.

Prefiero eliminar ramas después de que se fusionen. Esto evita el desorden visual de una larga lista de ramas en su repositorio. Estas ramas también se propagan a todas las bifurcaciones del repositorio.

Primero borro mi rama local. Esto evita que sea empujado accidentalmente más tarde.

git branch -d branchName

Luego borro la rama de seguimiento remoto

git branch -dr remoteName\branchName

Entonces borro la rama en GitHub. Utilizo la interfaz web, pero el comando equivalente está abajo.

git push remoteName :branchName

Incluso si la rama nunca fusionado, por lo general me gustaría mantener las confirmaciones para la posteridad. Sin embargo, todavía me gusta eliminar la rama. Para repartir las confirmaciones y evitar que sean consumidas por el recolector de basura, hago una etiqueta anotada que apunta a la misma confirmación que la rama eliminada.

git tag -a tagName commitOrBranchName

Luego envio la etiqueta a github

git push remoteName tagName

Parece que desea eliminar la rama 2011_Hotfix sin perder su historial. Hablaré primero de la eliminación y segundo de la historia.

Los métodos habituales de eliminación de ramas git ya se han descrito anteriormente, y funcionan como se esperaba. git no tiene un comando de una o dos palabras que signifique, "Hey git, borra tanto la rama local como la remota."Pero este comportamiento se puede imitar a través de un script de shell. Por ejemplo, tome el script de shell de Zach Holman 'git-nuke'. Es muy simple:

#!/bin/sh
git branch -D $1
git push origin :$1

Ponga esto en un archivo ejecutable (por ejemplo, git-nuke) en uno de sus directorios $PATH. Si no está en la rama 2011_Hotfix, simplemente ejecutando git-nuke 2011_Hotfix eliminará las ramas local y remota. Esto es mucho más rápido y simple though aunque quizás más peligroso than que los comandos estándar git.

Su preocupación por preservar la historia es buena. En este caso, no tienes que preocuparte. Una vez que combinas 2011_Hotfix en master, todas las confirmaciones de 2011_Hotfix se agregarán a master historial de confirmación. En resumen, no perderá la historia de una simple fusión.

Tengo una palabra más para agregar que quizás está más allá del alcance de su pregunta, pero es relevante de todos modos. Imaginemos que hay 20 pequeñas confirmaciones de "work-in-progress" en 2011_Hotfix; sin embargo, desea que solo se agregue una confirmación completa para 2011_Hotfix al historial de master. ¿Cómo combinas los 20 commits pequeños en un commit grande? Afortunadamente, git le permite consolidar múltiples confirmaciones en una confirmación mediante usando git-rebase. No voy a explicar aquí cómo funciona; aunque, si estás interesado, la documentación para git-rebase es excelente. Tenga en cuenta que git rebase reescribe la historia, por lo que debe usarse juiciosamente, especialmente si es nuevo en ella. Por último, su 2011_Hotfix escenario se trata de un equipo de desarrollo, no un solo dev. Si los miembros del equipo del proyecto usan git rebase, es aconsejable que el equipo tenga directrices explícitas sobre el uso de git rebase para que algún vaquero dev en el equipo no dañe involuntariamente el git ' s history.

Si se ha fusionado con éxito de nuevo y tal vez incluso etiquetado, entonces yo diría que ya no tiene uso. Así que usted puede hacer con seguridad git branch -d branchname.

Puede eliminar ramas en todas las principales UIs web, como github, BitBucket. Después de eliminar la rama en línea, puede eliminar la rama local usando

git remote prune origin