Pregunta Flujo de trabajo mercurial para ~ 15 desarrolladores. ¿Deberíamos usar ramas con nombre?


Mi equipo acaba de comenzar con Mercurial y un repositorio central. Tenemos a Hudson construyendo la punta de la rama "predeterminada", que es básicamente nuestra línea principal. Teníamos una política de check-in con nuestro VCS antiguo que las revisiones de códigos, pruebas, etc. deben hacerse antes de registrarse en la línea principal.

Entonces, digamos que estás trabajando en la característica X. Trabajas en algunas cosas, basándote en "predeterminado", y luego comprometes una función parcial como punto de control. Localmente, su "valor predeterminado" ahora está roto; todavía no lo ha compartido con nadie, pero si hiciera un esfuerzo, ahora tiene un código roto en la línea principal.

Incluso si espera a presionar hasta que lo haya solucionado todo, parece que hay situaciones (por ejemplo, trabajar en dos cosas a la vez) en las que tendría que realizar algunos cambios, pero no todos.

Además, si controlas todos los cambios de tu punto de control, habrá algunas revisiones en la línea principal que se compilará, y otras en la línea principal que no se compilan.

Hemos comenzado a usar ramas con nombre, pero mientras más leo, más creo que mal usamos ramas con nombre.

¿Alguna sugerencia sobre cómo configurar un buen flujo de trabajo que nos permita ejecutar Hudson y mantener nuestra política principal?


32
2018-02-26 16:50


origen


Respuestas:


Primero, lo recomiendo encarecidamente Una guía para la ramificación en Mercurial

A continuación, puede presionar solo la rama actual: Nudge - Una versión más suave de Push

Y tal vez podría decidir permitir solo una cabeza por rama: 32. Prevenir un empuje que crearía múltiples cabezas

Otras preguntas SO relacionadas con ramas nombradas:


18
2018-02-27 18:30



Puede considerar al menos dos repositorios. El repositorio "mainline" tiene su código probado y revisado. El código solo se envía a este repositorio después de que Hudson lo haya probado y después de las revisiones que haya realizado. El repositorio de "prueba" sería un clon de la línea principal. Este es el repositorio que Hudson monitorea, por lo que cada vez que se envía un conjunto de cambios al repositorio de pruebas, Hudson lo prueba. Probablemente pueda configurar un paso de compilación Hudson que impulse los cambios desde el repositorio de pruebas a su línea principal si las pruebas pasan.

Los desarrolladores siempre avanzan hacia el repositorio de pruebas, pero solo retiran de la línea principal, por lo que solo recurren al código probado. Si necesitan compartir conjuntos de cambios no probados, podrían empujar / jalar directamente entre los repositorios locales de los demás. Quizás es posible configurar Hg para que la línea principal solo acepte impulsos del repositorio de pruebas, de modo que los desarrolladores no puedan presionar accidentalmente a la línea principal en lugar de probar.

También podría ser bueno tener un repositorio de revisión. Así que los desarrolladores presionan para que se realicen las pruebas, Hudson empuja el código probado para revisarlo, y luego el código revisado se envía a la línea principal.

Descargo de responsabilidad: solo he usado Hg en proyectos triviales y de manera trivial.


2
2018-02-26 17:01



Lo que hacemos en mi compañía es utilizar la rama denominada para distinguir la versión estable (en la que solo corregimos las correcciones de errores) y la próxima versión en la que ocurre el desarrollo y respaldamos correcciones de estable a predeterminado de forma regular (con hg merge stable en la rama predeterminada).

Para la revisión del código, usamos la extensión mq para permitir a los desarrolladores enviar parches limpios. Y los desarrolladores pueden extraer de los depósitos de los demás, sin contaminar el repositorio de referencia.

Descargo de responsabilidad: no usamos Hudson.


2
2018-02-26 17:04



Es una cuestión de mentalidad. Los VCS distribuidos no requieren que mantenga un único depósito central.

En lugar de tener la línea principal abierta para que todos la puedan registrar, configúrela con acceso de escritura limitado. Solo los conjuntos de cambios que han sido aprobados (probados, firmados, lo que sea lógico para usted) se incorporan a la línea principal.

La forma de administrar los cambios en la línea principal es una pregunta abierta con muchas respuestas posibles. Aquí hay dos fuera de mi cabeza:

  • Los desarrolladores pueden ingresar libremente a un repositorio central de "pruebas", desde el cual se revisan los cambios.
  • Haga que los desarrolladores publiquen changesets en sus propias estaciones de trabajo (recuerde, las sucursales son baratas) y haga que el proceso de revisión principal los recoja directamente desde allí.

2
2018-02-26 20:16



También podría considerar usar el Marcadores extensión en lugar de ramas con nombre.

Si está familiarizado con git, los marcadores se comportan como git-branches en lugar de mercurial branches.


0
2017-11-18 05:12