git - comandos - ¿Por qué debo eliminar las ramas de características cuando se fusiona para dominar

git push

Question

La mayoría de los flujos de trabajo de git que he visto sugieren eliminar una branch después de que se haya fusionado en el maestro. Por ejemplo, este gitflow sugiere lo siguiente:

# Incorporating a finished feature on develop 
$ git checkout develop
Switched to branch ''develop''
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

¿Por qué debería eliminar la rama? También tengo curiosidad por saber qué hacer cuando más tarde se descubra un error que fue introducido por la función. ¿Debo crear la rama con el mismo nombre otra vez, corregir el error allí, fusionarse en el maestro y volver a eliminar la rama?

Answer 1

Algo importante es darse cuenta de que las ramas de Git no son más que una etiqueta que apunta a un compromiso. La ramificación en Git es literalmente ramificación. Así es como se ve un repositorio si la feature bifurca del master cuando el master es un commit B.

A - B - C - F - H [master]
     /
      D - E - G - I[feature]

¿Ver? Rama actual. Cuando git merge feature en maestro, obtienes esto.

A - B - C - F - H - J [master]
     /             /
      D - E - G - I  [feature]

¡Y una vez que hayas conseguido la git branch -d feature el historial de la rama!

A - B - C - F - H - J [master]
     /             /
      D - E - G - I

J tiene a los padres H y I. J no puede existir sin ellos, se basa en cómo funciona Git. No puedo existir sin G. G no puede existir sin E. Y así sucesivamente. La rama debe permanecer

J es una confirmación de fusión que normalmente contendrá el nombre de la rama que se está fusionando. Es como cualquier otro compromiso, por lo que incluso puede agregarle más información, como un enlace a su rastreador de problemas.

git merge --no-ff se usa para evitar que Git haga un "avance rápido" y pierda el historial de sucursales. Esto sucede si no se ha realizado ningún trabajo en el master desde que se creó la rama. Un avance rápido se ve así.

A - B[master]- D - E - G - I [feature]

git checkout master
git merge feature

A - B - D - E - G - I [feature] [master]

Dado que el master es un antecesor directo de la feature , no se requiere fusión. Git solo puede mover la etiqueta master . Tu historial de sucursales se ha perdido, parece que D, E, G y yo estuvimos hechos como confirmaciones individuales en el maestro. git merge --no-ff le dice a Git que nunca haga esto, que siempre realice una combinación.

En el futuro, cuando se note que se introdujo un error en G, cualquiera que navegue por el repositorio puede ver que se hizo como parte de la rama, mirar hacia adelante para encontrar el compromiso de fusión y obtener información sobre la rama desde allí.

Aun así, ¿por qué eliminar la rama? Dos razones. Primero, llenará tu lista de ramas con ramas muertas.

Segundo, y más importante, le impide reutilizar la rama. La ramificación y la fusión son complicadas. Las ramas de funciones de un solo uso y de corta duración simplifican el proceso al garantizar que solo una vez se fusione la rama con el maestro una vez . Esto elimina muchos problemas técnicos y de gestión. Cuando fusionas una rama, se hace . Si necesita solucionar un problema introducido en esa rama, simplemente trátelo como un error en el maestro y cree una nueva rama para solucionarlo.

Desafortunadamente, el git log corresponde al usuario y presenta una representación lineal del historial que no es lineal. Para solucionar esto, use git log --graph --decorate . Esto dibujará líneas como en mis ejemplos anteriores y le mostrará las ramas y etiquetas en cada confirmación. Obtendrá una vista mucho más verdadera del repositorio.

Si estás en una Mac, GitX visualizará el repositorio por ti. gitk es la versión genérica.

Answer 2

Debido a que el historial de la rama myfeature representa todos los compromisos intermedios realizados para implementar myfeature .

Esta estrategia mantiene solo un compromiso en el master , y se olvida de los pasos intermedios, lo que tiene sentido para las sucursales de larga duración, como expliqué en " ¿Por qué git fast-forward se fusiona de forma predeterminada? ".

El mensaje de confirmación del compromiso realizado (fusionado) en el master debe dejar claro que está hecho para implementar '' myfeature ''.

Si necesita ser reparado, el nombre de la rama se puede reutilizar (ya que se eliminó anteriormente).