Pregunta git branch nombrando las mejores prácticas [cerrado]


He estado usando un repositorio git local interactuando con el repositorio CVS de mi grupo durante varios meses, ahora. He creado un número casi neurótico de ramas, la mayoría de las cuales afortunadamente se fusionaron en mi tronco. Pero el nombramiento comienza a ser un problema. Si tengo una tarea fácilmente nombrada con una etiqueta simple, pero la logro en tres etapas, cada una de las cuales incluye su propia rama y fusión, entonces puedo repetir el nombre de la rama cada vez, pero eso hace que la historia sea un poco confusa. Si me vuelvo más específico en los nombres, con una descripción separada para cada etapa, los nombres de las ramas comienzan a ser largos y poco manejables.

Aprendí a mirar a través de viejos hilos aquí que podría comenzar a nombrar ramas con un / en el nombre, es decir, tema / tarea, o algo así. Puedo comenzar a hacer eso y ver si ayuda a mantener las cosas mejor organizadas.

¿Cuáles son algunas de las mejores prácticas para nombrar git branches?

Editar: Nadie ha sugerido ninguna convención de nombres. Borro ramas cuando termino con ellas. Simplemente tengo varios alrededor debido a que la administración ajusta constantemente mis prioridades. :) Como un ejemplo de por qué podría necesitar más de una sucursal en una tarea, supongo que necesito asignar el primer hito discreto en la tarea al depósito de CVS del grupo. En ese momento, debido a mi interacción imperfecta con CVS, realizaría esa confirmación y luego mataría esa rama. (He visto demasiada rareza interactuando con CVS si trato de seguir usando la misma rama en ese punto).


787
2017-11-07 21:29


origen


Respuestas:


Aquí hay algunas convenciones de nomenclatura de ramas que utilizo y las razones para ellas

Convenciones de nomenclatura de sucursales

  1. Use tokens de agrupamiento (palabras) al comienzo de los nombres de sus ramas.
  2. Defina y use tokens cortos para diferenciar ramas de una manera que sea significativa para su flujo de trabajo.
  3. Use barras inclinadas para separar partes de los nombres de sus ramas.
  4. No use números desnudos como partes principales.
  5. Evite nombres descriptivos largos para ramas de larga vida.

Tokens de grupo

Use tokens de "agrupamiento" delante de los nombres de sus ramas.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

Los grupos se pueden nombrar como lo desee para que coincida con su flujo de trabajo. Me gusta usar nombres cortos para el mío. Sigue leyendo para mayor claridad.

Fichas cortas bien definidas

Elija tokens cortos para que no agreguen demasiado ruido a cada uno de los nombres de las ramas. Yo uso estos:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Cada uno de estos tokens se puede usar para indicarle a qué parte de su flujo de trabajo pertenece cada rama.

Parece que tienes múltiples ramas para diferentes ciclos de un cambio. No sé cuáles son sus ciclos, pero supongamos que son 'nuevos', 'probar' y 'verificados'. Puede nombrar sus sucursales con versiones abreviadas de estas etiquetas, siempre escritas de la misma manera, tanto para agruparlas como para recordarle en qué etapa se encuentra.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Puede saber rápidamente qué ramas han alcanzado cada etapa diferente, y puede agruparlas fácilmente utilizando las opciones de coincidencia de patrones de Git.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Use barras inclinadas para separar las partes

Puede usar la mayoría de los delimitadores que desee en los nombres de las sucursales, pero considero que las barras son las más flexibles. Es posible que prefiera usar guiones o puntos. Pero las barras inclinadas le permiten hacer un cambio de nombre de rama al empujar o ir hacia o desde un control remoto.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Para mí, las barras también funcionan mejor para la expansión de pestañas (finalización del comando) en mi caparazón. La forma en que lo tengo configurado Puedo buscar ramas con diferentes subpartes escribiendo los primeros caracteres de la parte y presionando la tecla TAB. Zsh luego me da una lista de ramas que coinciden con la parte del token que he tipeado. Esto funciona tanto para tokens anteriores como incrustados.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell es muy configurable sobre la finalización del comando y también pude configurarlo para manejar guiones, guiones bajos o puntos de la misma manera. Pero elijo no hacerlo).

También te permite buscar ramas en muchos comandos de git, como este:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Advertencia: como señala Slipp en los comentarios, las barras pueden causar problemas. Como las ramas se implementan como rutas, no puede tener una rama llamada "foo" y otra rama llamada "foo / bar". Esto puede ser confuso para los nuevos usuarios.

No use números desnudos

No use números desnudos (o números hexadecimales) como parte de su esquema de nombres de sucursales. Dentro de la expansión de tabulación de un nombre de referencia, git puede decidir que un número es parte de un sha-1 en lugar de un nombre de rama. Por ejemplo, mi rastreador de problemas nombra errores con números decimales. Nombro mis ramas relacionadas CRnnnnn en lugar de solo nnnnn para evitar confusiones.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Si intentara expandir solo 15032, git no estaría seguro de si quería buscar SHA-1 o nombres de ramas, y mis opciones serían algo limitadas.

Evitar nombres descriptivos largos

Los nombres largos de las sucursales pueden ser muy útiles cuando mira una lista de sucursales. Pero puede interferir cuando se observan los registros de una sola línea decorados, ya que los nombres de las ramas pueden consumir la mayor parte de la línea individual y abreviar la parte visible del registro.

Por otro lado, los nombres de las ramas largas pueden ser más útiles en "fusiones de fusión" si habitualmente no las reescribes a mano. El mensaje de compromiso de fusión predeterminado es Merge branch 'branch-name'. Puede que le resulte más útil que aparezcan los mensajes de combinación como Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' en lugar de simplemente Merge branch 'fix/CR15032'.


714
2018-05-19 23:25



Un exitoso modelo de ramificación de Git por Vincent Driessen tiene buenas sugerencias. Una imagen esta abajo. Si este modelo de ramificación atrae a usted considere la extensión de flujo a git. Otros tienen comentó sobre el flujo

El modelo de Driessen incluye

  • Una rama principal, utilizada solo para lanzamiento. Nombre típico master.

  • Una rama de "desarrollo" fuera de esa rama. Ese es el que se usa para la mayoría del trabajo de la línea principal. Comúnmente llamado develop.

  • La función múltiple se ramifica fuera de la rama de desarrollo. Nombre basado en el nombre de la función. Estos se fusionarán de nuevo en desarrollo, no en las ramas maestra o de lanzamiento.

  • Divulgación de publicación para mantener versiones candidatas, con solo correcciones de errores y sin nuevas funciones. Nombre típico rc1.1.

Las revisiones son ramas efímeras para los cambios que provienen del maestro y entrarán en el maestro sin que esté involucrada la rama de desarrollo.

enter image description here


227
2017-11-23 16:58



Mi preferencia personal es eliminar el nombre de la rama una vez que haya terminado con una rama de tema.

En lugar de tratar de usar el nombre de la rama para explicar el significado de la rama, comienzo la línea de asunto del mensaje de confirmación en la primera confirmación en esa rama con "Sucursal:" e incluyo más explicaciones en el cuerpo del mensaje si el sujeto no me da suficiente espacio

El nombre de la rama en mi uso es puramente un asa para referirse a una rama de tema mientras se trabaja en ella. Una vez que el trabajo en la rama del tema ha concluido, me deshago del nombre de la rama, a veces etiquetando el compromiso para referencia posterior.

Eso hace que la salida de git branch más útil también: solo enumera las ramas de larga vida y las ramas de temas activos, no todas las ramas alguna vez.


42
2017-11-07 21:51



Mezclé y combiné diferentes esquemas que he visto y en base a las herramientas que estoy usando. Entonces, mi nombre completo de la sucursal sería:

name / feature / issue-tracker-number / short-description

que se traduciría en:

mike / blogs / RSSI-12 / logo-fix

Las partes están separadas por barras diagonales porque se interpretan como carpetas en SourceTree para facilitar la organización. Usamos Jira para nuestro seguimiento de problemas, por lo que incluir el número facilita la búsqueda en el sistema. Incluir ese número también hace que se pueda buscar cuando se intenta encontrar ese problema dentro de Github cuando se intenta enviar una solicitud de extracción.


25
2017-10-10 15:58



¿Por qué se necesitan tres ramas / fusiones para cada tarea? ¿Puedes explicar más sobre eso?

Si usa un sistema de seguimiento de errores, puede usar el número de error como parte del nombre de la rama. Esto mantendrá los nombres de las ramas únicos, y puede ponerles un prefijo o una palabra breve y descriptiva para mantenerlos legibles, como por ejemplo "ResizeWindow-43523". También ayuda a facilitar las cosas cuando va a limpiar las ramas, ya que puede buscar el error asociado. Así es como suelo nombrar mis ramas.

Dado que estas ramas finalmente se fusionarán de nuevo en el maestro, deberías estar seguro de eliminarlas después de fusionarte. A menos que te estés fusionando con --squash, toda la historia de la rama seguirá existiendo en caso de que la necesites.


19
2017-11-11 06:24



Tenga en cuenta, como se ilustra en el cometer e703d7 o cometer b6c2a0d  (Marzo de 2014), ahora parte de Git 2.0, encontrará otra convención de nombres (que puede aplicar a las sucursales).

"Cuando necesitas usar el espacio, usa el guión" es una manera extraña de decir que no debes usar un espacio.
  Debido a que es más común que las descripciones de línea de comando usen palabras múltiples discontinuas, ni siquiera desea utilizar espacios en estos lugares.

Un nombre de sucursal no puede tener espacio (ver "¿Qué personajes son ilegales dentro de un nombre de rama?"y git check-ref-format página man)

Entonces, para cada nombre de rama que estaría representado por una expresión de varias palabras, usando un '-'(guión) como separador es una buena idea.


7
2018-06-14 19:41



Siguiendo con la sugerencia de farktronix, hemos estado usando los números de los tickets de Jira para mercurial similar, y estoy planeando seguir usándolos para git branches. Pero creo que el número del ticket en sí mismo es probablemente lo suficientemente único. Si bien puede ser útil tener una palabra descriptiva en el nombre de la rama, como notó Farktronix, si se cambia de una rama a otra con la suficiente frecuencia, es probable que desee escribir menos. Luego, si necesita conocer el nombre de la sucursal, busque en Jira las palabras clave asociadas en el boleto si no lo sabe. Además, debe incluir el número de ticket en cada comentario.

Si su sucursal representa una versión, parece que la convención común es usar el formato xxx (ejemplo: "1.0.0") para los nombres de las sucursales y vx.xx (ejemplo "v1.0.0") para los nombres de las etiquetas (para evitar conflictos) . Ver también: is-there-an-standard-naming-convention-for-git-tags


4
2018-01-27 21:31