Buena convención de nomenclatura para sucursales con nombre en {DVCS} de su elección


16

Estamos integrando Mercurial lentamente en nuestra oficina y haciendo desarrollo web comenzamos a usar sucursales con nombre.

Sin embargo, no hemos encontrado una buena convención en cuanto a nombrar nuestras sucursales.

Nosotros tratamos:

  • FeatureName (puede ver que esto causa un problema más adelante)
  • DEVInitial_FeatureName (podría ser confuso cuando el desarrollador entra y sale de la línea)
  • {uniqueID (int)} _ Característica

Hasta ahora, el uniqueID_featureName está ganando, estamos pensando en mantenerlo en una pequeña base de datos solo como referencia.

Tendría: branchID (int), featureName (varchar), featureDescription (varchar), fecha, quién, etc.

Esto nos daría ramas como: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... y tendríamos una referencia fácil de lo que hace esa rama sin tener que verificar el registro.

¿Alguna mejor solución por ahí?

Respuestas:


14

Si no tiene un rastreador de problemas, le recomiendo configurar uno y luego usar {nombre del rastreador de problemas} _ {número de ticket}. Cuando alguien a partir de ahora presente un error y no sepa exactamente cómo se suponía que debía funcionar la función, será fácil anotar el archivo y volver a donde el usuario puede haber solicitado esa funcionalidad exacta.


Acordamos que tenemos un rastreador de errores y estamos planeando usar el ID de error en el nombre de la sucursal para corregirlos. Mi pregunta era más para un desarrollo totalmente nuevo, cuando no estás arreglando nada más que agregar algo totalmente nuevo. Supongo que podríamos crear un boleto de mejora tonto e ir desde allí.
jfrobishow

55
Absolutamente debería crear entradas para nuevas funciones. El trabajo también debe ser rastreado. +1 por requerir una identificación única.
AShelly

Si se asegura de poner todos los detalles de las nuevas funciones en el rastreador, alguien más tarde puede verificar si está funcionando según lo diseñado o si realmente hay un error. Trabajo en un equipo de desarrollo que mantiene un programa de más de 5 años. Hay momentos en los que el cliente presenta un error y cuando lo investigamos encontramos que funciona según lo diseñado y el desarrollador original y el solicitante original desaparecieron. Tenemos situaciones similares en las que no sabemos por qué algo es así y si las características no estuvieran en el rastreador no tendríamos forma de averiguarlo.
Asa Ayers

2

Sugiero que sea simple y nombre las ramas de acuerdo con la FeatureName(o feature-name) convención. Sí, esto significa un espacio de nombres compartido, pero rara vez es un problema en el mundo real. Una vez que se hace una función y se fusiona completamente con la línea principal, la rama se puede eliminar de forma segura.

La idea principal del control de versión distribuido es que debería ser fácil ramificarse, introducir burocracia adicional, como la identificación única obligatoria, solo va a hacer esto más difícil.


1
Estoy de acuerdo, este es el camino a seguir. ¿En qué mundo tendrías tantas ramas que no puedas evitar la colisión?
alternativa

Es justo que obtener una descripción vinculada al nombre supongo que es más importante para nosotros ... el commit inicial debería contenerlo, pero no conozco ninguna forma de extraerlo rápidamente.
jfrobishow

1
En un gran entorno corporativo, permitir que los desarrolladores inventen nombres para las funciones provocará dolores de cabeza tarde o temprano.
AShelly

1
Ya veo, porque en el "gran entorno corporativo" no se puede confiar en los desarrolladores. Pero espere, también inventan nombres para variables, funciones y archivos. ¡Deberíamos establecer un comité para controlar eso también! (ironía)
Adam Byrtek

2

Recomiendo usar dicho formulario (como ejemplo):

BUG_ID
ID DE ERROR #
IDENTIFICACIÓN DE ENTRADAS
IDENTIFICACIÓN DE ENTRADAS
feature_bla-bla-bla
release-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Simplemente seleccione buenos prefijos (para permitir la salida del filtro de las ramas hg ), la regla de mayúsculas y el delimitador entre el prefijo y la ID / nombres.


Hicimos +1 con BUGID_ {freeCamelCasedTextDescription} al final.
jfrobishow
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.