it-swarm-es.com

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

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

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

Nosotros tratamos:

  • FeatureName (puede ver que esto causa problemas en el futuro)
  • DEVInitial_FeatureName (podría resultar confuso cuando el desarrollador entra y sale de la línea)
  • {UniqueID (int)} _ Función

Hasta ahora, 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 revisar el registro.

¿Alguna solución mejor por ahí?

16
jfrobishow

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 dentro de unos años presente un error y no sepa exactamente cómo se suponía que funcionaba la función, será fácil anotar el archivo y volver a donde el usuario puede haber solicitado esa funcionalidad exacta.

14
Asa Ayers

Recomiendo usar dicho formulario (como ejemplo):

 BUG_ID 
 BUG # ID 
 TICKET_ID 
 TICKET # ID 
 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 de filtro de hg ramas), la regla de uso de mayúsculas y el delimitador entre prefijo e ID/nombres.

2
gavenkoa

Sugiero mantenerlo simple y nombrar las ramas de acuerdo con 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 una función está lista y completamente fusionada con la línea principal, la rama se puede eliminar de manera segura.

La idea principal del control de versiones distribuidas es que debería ser fácil de bifurcar, la introducción de burocracia adicional, como la identificación única obligatoria, solo hará que esto sea más difícil.

2
Adam Byrtek