¿Pueden / deberían evitarse las fusiones frecuentes (p. Ej., Por rebase)?

Estoy trabajando en un proyecto más grande en un equipo de 5 desarrolladores y estamos utilizando Mercurial como VCS.

Todos tendemos a trabajar y comprometernos localmente hasta que consideremos que una característica / arreglo está list para ser empujada y luego fusionar e impulsar nuestros cambios. Usualmente presiono (y por lo tanto me uno con el control remoto) varias veces al día, como lo hacen la mayoría de los demás.

Esto a menudo conduce a un "desorder de fusión": múltiples desarrolladores extraen, fusionan y empujan sets de cambios. La historia resultante no es muy bonita, y a veces se ve así:

fusionar desorden

Dudo que uno pueda aislar un set de cambios específico en ese lío, o incluso descubrir cómo / qué afectó de qué manera (al less me estremezco ante la perspectiva).

Si las fusiones fueran necesarias, la historia anterior estaría bien, supongo, pero la mayoría de estas fusiones podrían evitarse (de forma segura) al volver a basar, ya que cada desarrollador trabaja en tareas específicas que están más o less aisladas del rest.

La verdadera pregunta:

  • ¿Es "normal" que los historiales de VCS se parezcan a los de arriba? ¿Deberían evitarse tales historias?
  • ¿Cómo se puede evitar esa historia?

Acerca de la parte "evitar": dado que las tareas en las que trabajamos están algo aisladas (Backend, Frontend, Web), podríamos dividirlas en sucursales o incluso separar repositorys. Sin embargo, los proyectos no son completamente independientes entre sí, así que supongo que dividirse en varios repos causa más dolor que ganancia. No estoy seguro de si las twigs con nombre sería mucho mejor, ya que constantemente tenemos más de 3 twigs allí, que deberían fusionarse con mayor frecuencia en el tronco.

Rebase parece una opción, especialmente dado que muchos sets de cambios son completamente independientes entre sí, sin embargo, esto pone la carga de decidir si volver a establecer la base o no en el desarrollador. Puede haber conflictos y luego uno debería fusionarse después de todo. Esto puede llevar a que las personas no cambien de base en primer lugar, así que volvemos a donde estamos ahora.

En este momento no puedo pensar en otra opción para hacer que la historia se vea más limpia. Puede que ahora no sea un gran problema, pero ¿qué sucede cuando de repente hay 20 desarrolladores? Si la historia es un gran laberinto, ¿qué sentido tiene? Considero que es difícil rastrear los efectos de un set de cambios si hay docenas de intersecciones.

Lo que estás viendo es, más o less, lo que se supone que debe suceder cuando tienes varios desarrolladores trabajando en el mismo repository.

La única forma de evitarlo es reescribir el historial, especialmente si ha realizado confirmaciones locales. Tendrás que tirar, rebase, y luego empujar.

Editar: hay una cosa sobre tu gráfico de revisión que me llama la atención. Hay una gran cantidad de sucursales de sucursales y la fusión a través de estas sucursales secundarias. Se ve, bueno, caótico. Si su ramificación y fusión es tan caótica como parece, quizás su equipo podría beneficiarse de un enfoque más estructurado para la bifurcación y la fusión.

El "Modelo de ramificación de Git exitoso" que inspiró el flujo de git puede aplicarse también a los repositorys de Mercurial. hgflow es una extensión que ayuda a implementarlo.

Si eso parece demasiada estructura, entonces siempre puedes encontrar otro path a seguir. Sin embargo, podría valer la pena pensar un poco y llamar la atención de su equipo.

Ver también: commit-pull-merge-push o pull-merge-commit-push?

Sí, use rebase y evite que Noisy se fusione es seguro (desde hg-2.1) y simple .

Eres un pequeño equipo de 5 desarrolladores. Toda la fusión anterior probablemente ocurra porque "hice algo de compromiso en la parte X al mismo time que Bob trabajó en la parte Y" . Esas fusiones no aportan información útil y a nadie le importa utilizar sus micro sucursales de forma independiente.

Mantener las twigs en su historial es útil cuando hay una buena semántica para esto (por ejemplo, una twig estable para correcciones de errores, una twig pnetworkingeterminada para nuevas características) o cuando un cambio tardó en madurar y merece fusionarse con otros. Otras fusiones son solo ruido para mí.

Desde la introducción de las fases (Mercurial 2.1), es muy seguro usar rebase como (de manera pnetworkingeterminada) Mercurial le permitirá volver a establecer la base de los sets de cambios locales solamente. Tu nuevo flujo de trabajo puede ser similar a:

  • clon
  • cortar
  • cometer
  • cortar
  • cometer
  • Halar
  • rebase
  • testing
  • empujar

Estás mirando demasiados niveles de abstracción y luego te quejas de que parece demasiado complejo. Existe una opción para limitar su vista a la línea principal de su sucursal. Úselo. Solo profundice en la fusión en sucursales si tiene una necesidad específica. Es mejor tener el historial disponible e innecesario que destruirlo con una rebase.