Cuándo eliminar ramas en Git?

Question

Supongamos que tenemos una aplicación estable.

Mañana, alguien informa de un gran error que decidimos actualizar de inmediato. Así que creamos una rama para esa revisión fuera de "master", la llamamos "2011_Hotfix", y la realizamos para que todos los desarrolladores puedan colaborar para solucionarla.

Arreglamos el error y fusionamos "2011_Hotfix" en "maestro", así como en la rama de desarrollo actual. Y presione "maestro".

¿Qué hacemos con "2011_Hotfix" ahora? ¿Debería sentarse allí como una sucursal para siempre hasta el final de los tiempos o deberíamos ahora eliminarlo, ya que ha cumplido su propósito? Parece sucio dejar las ramas por todas partes, ya que la lista de ramas probablemente sea muy larga, la mayoría de las cuales ni siquiera son necesarias.

En caso de que deba eliminarse, ¿qué pasará con su historial? ¿Se mantendrá eso, aunque la rama real ya no esté disponible? Además, ¿cómo eliminaría una rama remota?

Answer 1

Puede quitar con seguridad una rama con git branch -d yourbranch. Si contiene cambios no fusionados (es decir, perdería compromisos al eliminar la rama), git se lo indicará y no lo eliminará.

Por lo tanto, eliminar una rama fusionada es barato y no le hará perder ningún historial.

Para eliminar una rama remota, use git push origin :mybranch, suponiendo que su nombre remoto es origen y la rama remota que desea eliminar se llama mybranch.

Answer 2

Si se ha fusionado con éxito nuevamente y tal vez incluso etiquetado, entonces diría que ya no tiene uso. Entonces puede hacer git branch -d branchname de manera segura.

Answer 3

Lo que debes hacer es etiquetar todo lo que liberes. Mantenga las ramas para cuando esté desarrollando activamente.

ramas viejas de borrado con

git branch -d branch_name 

eliminarlos del servidor con

git push origin --delete branch_name 

o la sintaxis de edad

git push origin :branch_name 

cuyo texto es el "empujar nada en branch_name en origen" .

Dicho esto, siempre que el DAG (gráfico acíclico dirigido) pueda señalarlo, los commits estarán allí en la historia.

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

Answer 4

Dado que la cuestión tiene la etiqueta "github", también me añadir lo siguiente: concretamente en Github, si pull-petición una rama y se fusionó (ya sea a través de la interfaz de usuario o mediante la fusión de la sucursal de la solicitud de extracción), no perderá los datos de solicitud de extracción (incluidos los comentarios), , incluso si elimina la rama.

Una consecuencia de esto: si incorpora solicitudes de extracción como parte de su flujo de trabajo (que se combina dulcemente con revisiones de código), puede eliminar sucursales de manera segura tan pronto como se fusionen. Esto es tan común que recientemente Github agregó una característica (dulce) que muestra un botón de "eliminar sucursal" justo después de fusionar una solicitud de extracción.

Pero vale la pena observar que cada grupo debe adoptar el flujo de trabajo que más le convenga (y puede o no llevar a eliminar tales ramas). Mi equipo de trabajo actual, por ejemplo, poda todas las ramas que no son maestras o relacionadas con la implementación (por ejemplo, producción, puesta en escena, etc.) tan pronto como sus solicitudes de extracción se fusionan, y todavía tenemos un seguimiento completo de cómo se formaron las confirmaciones relacionadas. cada mejora incremental de cada producto.

Por supuesto, ninguna gestión de historial (solicitudes de extracción o de otro tipo) reemplaza el etiquetado correcto de las versiones (que preferiblemente automatiza con la misma herramienta/script que implementa/empaqueta una versión), de modo que siempre puede cambiar rápidamente a sus usuarios sucede estar en un momento dado. El etiquetado también es la clave para resolver su problema original: si establece que cualquier rama fusionada con las ramas de "trabajo" puede y debe eliminarse, y que cualquiera que se haya combinado con una etiqueta de versión, "producción", etc. no debería , siempre tendrá las revisiones activas hasta que estén integradas en una versión futura.

Answer 5

Yo agregaría que la desventaja de eliminar sucursales es que romperá cualquier hipervínculo a esas ramas en GitHub (esta pregunta está etiquetada github). Obtendrá un error 404 Not Found para esos enlaces. Esta es la razón por la que cambio mis enlaces para apuntar 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 el enlace a una confirmación o etiqueta desde el primer día.

Prefiero eliminar las ramas después de que están fusionadas. 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 sucursal local. Esto evita que sea empujado accidentalmente más tarde.

git branch -d branchName 

Luego borrar la rama seguimiento remoto

git branch -dr remoteName\branchName 

Luego borro la rama en GitHub. Uso la interfaz web, pero el comando equivalente está debajo.

git push remoteName :branchName 

Incluso si la rama nunca se fusiona, normalmente me gustaría mantener las confirmaciones para la posteridad. Sin embargo, todavía me gusta eliminar la rama. Para distribuir las confirmaciones y evitar que el recolector de elementos no utilizados las consuma, hago una etiqueta anotada que apunte a la misma confirmación que la rama eliminada.

git tag -a tagName commitOrBranchName 

Entonces empuje la etiqueta a GitHub

git push remoteName tagName 

Answer 6

Parece que desea eliminar la rama 2011_Hotfix sin perder su historia. Discutiré la eliminación primero y la segunda 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 significa, "Hola git, elimine la rama local y remota". Pero este comportamiento se puede imitar a través del script de shell. Por ejemplo, tome Zach Holman's shell script 'git-nuke'. Es muy simple:

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

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

Su preocupación por preservar la historia es buena. En este caso, no debes preocuparte. Una vez que combine 2011_Hotfix en master, todas las confirmaciones de 2011_Hotfix se agregarán al historial de confirmaciones de master. En resumen, no perderás el historial 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 de todos modos es relevante. Imaginemos que hay 20 pequeñas confirmaciones de "trabajo en curso" en 2011_Hotfix; sin embargo, solo desea que se agregue una confirmación completa para 2011_Hotfix al historial de master. ¿Cómo combinas los 20 commits pequeños en un gran commit? Afortunadamente, git le permite consolidar varias confirmaciones en una confirmación utilizando git-rebase. No explicaré aquí cómo funciona eso; sin embargo, si está interesado, the documentation for git-rebase es excelente. Tenga en cuenta que git rebase reescribe el historial, por lo que debe usarse con prudencia, especialmente si es nuevo en él. Finalmente, su escenario 2011_Hotfix es sobre un equipo de desarrollo, no un desarrollador en solitario. 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 desarrollador de vaquero en el equipo no dañe involuntariamente el historial de un proyecto git.

Answer 7

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

git remote prune origin