Buen flujo de trabajo Mercurial para un equipo de 15 desarrolladores

Question

Estoy en un equipo de 15 desarrolladores que actualmente utilizan Allfusion Harvest. No estamos contentos con eso y mirando alrededor hemos decidido cambiar a Mercurial debido a las interfaces disponibles TortoiseHg y MercurialEclipse.

Actualmente estamos utilizando un lanzamiento de Harvest de doce años y encuentro que nuestro flujo de trabajo actual es difícil de traducir a Mercurial. Tengo experiencia previa con ClearCase donde se utilizó un modelo similar a:

A A A 
| | | 
B C | 
| /| | 
C | E 
| |/ 
D E 
|/
E 

Cuando el tronco izquierdo es inestable , medio es prueba y derecha es estable . Ahora no tengo problemas para recrear este modelo de ramificación en Mercurial (en un repositorio central). La idea es que los desarrolladores clonen este repositorio, se ramifiquen desde inestable, hagan su trabajo y luego se fusionen con inestable. Leyendo en la web aún no he visto un flujo de trabajo de Mercurial dirigido a equipos de más de tres desarrolladores, por lo que no estoy seguro si este es un buen flujo de trabajo.

Así que dos preguntas:

Este es un buen modelo de trabajo?

¿Cómo trabajas con Mercurial y cuántos hay en tu equipo?

EDITAR: Desde que hice esta pregunta, he usado tanto Gitflow como Github flow. Ambos han sido útiles dependiendo de la complejidad del lanzamiento y el tamaño del equipo. Y al usar Mercurial, he dejado de usar ramas (para otras que no sean estables/inestables) e hice uso de los marcadores influenciados por Git.

Answer 1

Aquí en Fog Creek, utilizamos un flujo de trabajo similar, con una gran diferencia. Debido a que no hay ramas ligeras en Mercurial (las ramas con nombre mantienen su nombre, incluso después de fusionarse), tendemos a utilizar varios repositorios para nuestras sucursales. Descubrí que esto facilita saber en qué rama está trabajando y también dificulta la fusión accidental entre las ramas, ya que cada una de sus ramas podría tener sucursales propias.

En su lugar, tenemos repositorios Stable, QA y Devel con los que trabajamos. El trabajo de las características entra en Devel y se combina con QA y Stable, mientras que las correcciones de errores entran en Stable y QA, y se fusionan de nuevo en Devel.

Muchos de nuestros desarrolladores también mantienen sus propios repositorios de sucursales para proyectos de ejecución más larga, o cualquier cosa en la que estén trabajando que pueda romper el código de otra persona.

Algunos de nuestros desarrolladores tienen cada rama en un directorio diferente, por lo que cambian explícitamente de una a otra. Otros prefieren juntar los tres en un repo, usando la extensión remote-branches para administrar las distintas cabezas.

Esto nos dio un poco de problema cuando estábamos usando el hg serve básico para alojar nuestros repositorios, ya que la creación de un nuevo desarrollo o el cambio de nombre requerían un administrador del sistema. Eso es parte de por qué lo hicimos para que cualquiera pueda crear repositorios de sucursales en Kiln.

Sería bueno si Mercurial tuviera un mejor modelo de ramificación, y hay algo de trabajo para ayudar con eso, pero esto es lo que funciona para nosotros.

Answer 2

• En la medida en que sé, su flujo de trabajo es bastante bueno.