git branch nombrando las mejores prácticas

He estado usando un repository git local interactuando con el repository CVS de mi grupo durante varios meses, ahora. He creado un número casi neurótico de twigs, 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 label simple, pero la logro en tres etapas, cada una de las cuales incluye su propia twig y fusión, entonces puedo repetir el nombre de la twig 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 twigs comienzan a ser largos y poco manejables.

Aprendí a mirar a través de viejos hilos aquí que podría comenzar a nombrar twigs 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 twigs cuando termino con ellas. Simplemente tengo varios alnetworkingedor debido a que la administración ajusta constantemente mis prioridades. 🙂 Como ejemplo de por qué podría necesitar más de una sucursal en una tarea, supongamos 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 twig. (He visto demasiada rareza interactuando con CVS si trato de seguir usando la misma twig en ese punto).

Aquí hay algunas convenciones de nomenclatura de twigs 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 twigs.
  2. Defina y use tokens cortos para diferenciar twigs de una manera que sea significativa para su flujo de trabajo.
  3. Use barras inclinadas para separar partes de los nombres de sus twigs.
  4. No use numbers desnudos como partes principales.
  5. Evite nombres descriptivos largos para twigs de larga vida.

Tokens de grupo

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

 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 twigs. 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 twig.

Parece que tienes múltiples twigs 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 tags, 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é twigs 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 twig 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 tabs (finalización del command) en mi caparazón. La forma en que lo tengo configurado Puedo search twigs con diferentes subpartes escribiendo los primeros caracteres de la parte y presionando la tecla TAB. Zsh luego me da una list de twigs que coinciden con la parte del token que he tipeado. Esto funciona tanto para tokens anteriores como embeddeds.

 $ 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 command y también pude configurarlo para manejar guiones, guiones bajos o puntos de la misma manera. Pero elijo no hacerlo).

También te permite search twigs en muchos commands de git, así:

 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 twigs se implementan como routes, no puede tener una twig llamada "foo" y otra twig llamada "foo / bar". Esto puede ser confuso para los nuevos usuarios.

No use numbers desnudos

No use numbers desnudos (o numbers hexadecimales) como parte de su esquema de nombres de sucursales. Dentro de la expansión de tabulación de un nombre de reference, git puede decidir que un número es parte de un sha-1 en lugar de un nombre de twig. Por ejemplo, mi rastreador de problemas nombra errores con numbers decimales. Nombro mis twigs 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 search SHA-1 o nombres de twigs, y mis opciones serían algo limitadas.

Evitar nombres descriptivos largos

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

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

Un exitoso model de ramificación de Git por Vincent Driessen tiene buenas sugerencias. Una image esta abajo. Si este model de bifurcación le atrae, considere la extensión de flujo a git . Otros han comentado sobre el flujo

El model de Driessen incluye

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

  • Una twig de "desarrollo" fuera de esa twig. Ese es el que se usa para la mayoría del trabajo de la línea principal. Nombre típico devel .

  • La function múltiple se ramifica fuera de la twig de desarrollo. Nombre basado en el nombre de la function. Estos se fusionarán de nuevo en desarrollo, no en las twigs 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 twigs efímeras para los cambios que provienen del maestro y entrarán en el maestro sin que esté involucrada la twig de desarrollo.

enter image description here

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

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

El nombre de la twig en mi uso es puramente un asa para referirse a una twig temática mientras se trabaja en ella. Una vez que el trabajo en la twig del tema ha concluido, me deshago del nombre de la twig, a veces labelndo el compromiso para reference posterior.

Eso hace que el resultado de la git branch de git branch más útil también: solo enumera las twigs de larga duración y las twigs de temas activos, no todas las twigs alguna vez.

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 include el número facilita la búsqueda en el sistema. Incluir ese número también hace que se pueda search cuando se intenta encontrar ese problema dentro de Github cuando se intenta enviar una request de extracción.

¿Por qué se necesitan tres twigs / 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 twig. Esto mantendrá los nombres de las twigs únicos, y puede ponerles un prefijo o una palabra breve y descriptiva para mantenerlos legibles, como "ResizeWindow-43523" . También ayuda a facilitar las cosas cuando va a limpiar las twigs, ya que puede search el error asociado. Así es como suelo nombrar mis twigs.

Dado que estas twigs finalmente se fusionarán de nuevo en el maestro, deberías estar seguro de eliminarlas después de fusionarte. A less que te estés fusionando con --squash , toda la historia de la twig seguirá existiendo si alguna vez la necesitas.

Tenga en count que, como se ilustra en commit e703d7 o commit b6c2a0d (marzo de 2014), que ahora forma 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 command usen palabras múltiples discontinuas, ni siquiera desea utilizar espacios en estos lugares.

Un nombre de sucursal no puede tener espacio (consulte " ¿Qué caracteres son ilegales dentro de un nombre de sucursal? " Y la página de git check-ref-format ).

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

Siguiendo con la sugerencia de farktronix, hemos estado usando los numbers 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 twig, como notó Farktronix, si se cambia de una twig a otra con la suficiente frecuencia, es probable que desee escribir less. Luego, si necesita conocer el nombre de la sucursal, busque en Jira las palabras key asociadas en el boleto si no lo sabe. Además, debe include 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 formatting xxx (ejemplo: "1.0.0") para los nombres de las sucursales y vx.xx (ejemplo "v1.0.0") para los nombres de las tags (para evitar conflictos) . Ver también: is-there-an-standard-naming-convention-for-git-tags