remota - Git rama nombrando mejores prácticas

git push example (7)

¿Por qué se necesitan tres sucursales / 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 prefijarlos con una o dos palabras cortas y descriptivas para que sean legibles para los humanos, como "ResizeWindow-43523" . También ayuda a facilitar las cosas cuando va a limpiar ramas, ya que puede buscar el error asociado. Así es como suelo nombrar mis ramas.

Dado que estas ramas finalmente se vuelven a fusionar en el maestro, debería estar seguro de eliminarlas después de fusionarlas. A menos que se esté fusionando con --squash , la historia completa de la sucursal seguirá existiendo si alguna vez la necesita.

He estado usando un repositorio local de git interactuando con el repositorio CVS de mi grupo durante varios meses, ahora. He hecho un número casi neurótico de ramas, la mayoría de las cuales afortunadamente se han vuelto a unir en mi tronco. Pero el nombramiento está empezando a convertirse en un problema. Si tengo una tarea fácil de nombrar con una etiqueta simple, pero la logro en tres etapas, cada una de las cuales incluye su propia rama y combinación de situaciones, entonces puedo repetir el nombre de la rama cada vez, pero eso hace que el historial sea un poco confuso. Si me vuelvo más específico en los nombres, con una descripción separada para cada etapa, entonces los nombres de las ramas comienzan a ser largos y difíciles de manejar.

Aprendí mirando a través de hilos viejos 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 sucursales de git?

Edit: Nadie ha sugerido realmente ninguna convención de nomenclatura. Borro ramas cuando termino con ellas. Resulta que tengo varios debido a que la administración ajusta constantemente mis prioridades. :) Como ejemplo de por qué podría necesitar más de una rama en una tarea, supongamos que debo enviar el primer hito discreto en la tarea al repositorio de CVS del grupo. En ese momento, debido a mi interacción imperfecta con CVS, realizaría ese commit y luego mataría esa rama. (He visto demasiada rareza interactuando con CVS si intento seguir usando la misma rama en ese momento).

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

Convenciones de nombres de rama

Use tokens (palabras) de agrupación al comienzo de los nombres de sus ramas.
Defina y use tokens de derivaciones cortas para diferenciar las ramas de una manera que sea significativa para su flujo de trabajo.
Utilice barras para separar partes de los nombres de sus sucursales.
No utilice números desnudos como partes principales.
Evite los nombres descriptivos largos para las ramas de larga vida.

Fichas de grupo

Use tokens de "agrupación" delante de los nombres de sus sucursales.

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

Los grupos pueden nombrarse como desee para que coincidan con su flujo de trabajo. Me gusta usar sustantivos cortos para los míos. Sigue leyendo para más claridad.

Fichas cortas bien definidas

Elija tokens cortos para que no agreguen demasiado ruido a cada uno de los nombres de sus sucursales. 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 cambio. No sé cuáles son sus ciclos, pero supongamos que son ''nuevos'', ''de prueba'' y ''verificados''. Puede nombrar sus sucursales con versiones abreviadas de estas etiquetas, siempre escritas de la misma manera, para agruparlas y 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 usando 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"

Usa barras para separar las partes

Puede usar la mayoría de los delimitadores que desee en los nombres de las sucursales, pero creo que las barras son las más flexibles. Es posible que prefiera utilizar guiones o puntos. Pero las barras diagonales le permiten hacer un cambio de nombre de rama al empujar o buscar desde / hacia 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 inclinadas también funcionan mejor para la expansión de pestañas (comando completado) en mi shell. De la forma en que lo tengo configurado, puedo buscar sucursales 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 escrito. Esto funciona tanto para tokens precedentes como para 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 acerca de la finalización del comando y también podría 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 git, como este:

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

Advertencia: como Slipp señala en los comentarios, las barras diagonales pueden causar problemas. Debido a que 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 uses números desnudos

No use números desnudos (o números hexadecimales) como parte de su esquema de denominación de sucursales. Dentro de la pestaña de expansió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 las ramas relacionadas con CRnnnnn en lugar de solo nnnnn para evitar confusiones.

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

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

Evitar nombres largos y descriptivos.

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

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

He mezclado y combinado diferentes esquemas que he visto y basados en las herramientas que estoy usando. Así que mi nombre completo de rama sería:

nombre / característica / número de rastreador de problemas / descripción breve

que se traduciría a:

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. Utilizamos Jira para el seguimiento de nuestros problemas, por lo que incluir el número hace que sea más fácil buscar 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.

Mi preferencia personal es eliminar el nombre de la rama después de que termine 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 de esa rama con "Rama:" e incluyo más explicaciones en el cuerpo del mensaje si el tema No me da suficiente espacio.

El nombre de la rama en mi uso es puramente un identificador para referirse a una rama temática mientras se trabaja en ella. Una vez que el trabajo en la rama temática ha concluido, me deshago del nombre de la rama, a veces etiquetando la confirmación para referencia futura.

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

Siguiendo con la sugerencia de farktronix, hemos estado usando los números de boletos de Jira para mercurial similar, y estoy planeando continuar usándolos para las sucursales de git. Pero creo que el número del boleto en sí es probablemente lo suficientemente único. Si bien puede ser útil tener una palabra descriptiva en el nombre de la rama como anotó farktronix, si está cambiando entre las ramas con la frecuencia suficiente, probablemente quiera menos escribir. Luego, si necesita saber el nombre de la rama, busque en Jira las palabras clave asociadas en el ticket si no lo sabe. Además, debes incluir el número de ticket en cada comentario.

Si su rama 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 ramas y vx.xx (ejemplo "v1.0.0") para los nombres de etiquetas (para evitar conflictos) . Vea también: is-there-an-standard-naming-convention-for-git-tags

Tenga en cuenta que, como se ilustra en el commit e703d7 o commit 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 tablero" es una forma extraña de decir que no debes usar un espacio.
Debido a que es más común que las descripciones de la línea de comandos usen múltiples palabras con guiones, ni siquiera desea usar espacios en estos lugares.

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

Por lo tanto, para cada nombre de rama que se represente con una expresión de varias palabras, es una buena idea usar un '' - '' (guión) como separador.

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

El modelo de Driessen incluye

Una rama maestra, utilizada solo para liberar. Nombre típico master .
Una rama de "desarrollo" de esa rama. Ese es el que se usa para la mayoría de los trabajos de línea principal. Comúnmente llamado develop .
Característica múltiple se ramifica fuera de la rama desarrollada. Nombre basado en el nombre de la característica. Estos se fusionarán de nuevo en desarrollo, no en las ramas maestra o de lanzamiento.
Libere la rama para mantener las versiones candidatas, con solo correcciones de errores y sin nuevas funciones. Nombre típico rc1.1 .

Las revisiones son sucursales de corta duración para los cambios que provienen del maestro y entrarán en el maestro sin que se involucre una rama de desarrollo.