¿Se puede considerar la ramificación como una mala práctica? [duplicar]

12

Un compañero de trabajo está en contra de la ramificación. Yo uso ramificación todo el tiempo. Puse al equipo en un sistema básico de 3 ramas. Creo mis propias ramas de características. Dicho compañero de trabajo tiende a tener buenas ideas, sigue las mejores prácticas y tiendo a estar de acuerdo con él en muchas de estas cosas. Excepto esto.

Las tiendas de software exitosas sobre las que he leído: Microsoft, Google, fogcreek, todas usan ramificación. Mi compañero de trabajo argumenta que debido a la forma en que funciona nuestra tienda (campo médico), la ramificación causa problemas. En cambio, dice que deberíamos crear muchos proyectos pequeños (archivos * .csproj) y nunca trabajar en el mismo código al mismo tiempo.

Estoy de acuerdo, tenemos problemas con la fusión. Argumento que la causa principal de estos problemas es la falta de comunicación con el equipo y la falta de conocimiento sobre cómo utilizar correctamente nuestro sistema de control de origen para que funcione correctamente (TFS). Considero que su enfoque es la programación en Silo y una pesadilla de gestión de DLL.

¿Hay situaciones en las que la bifurcación es una mala idea? ¿Estoy equivocado?

    
pregunta P.Brian.Mackey 16.01.2013 - 15:29

7 respuestas

11

Recomiendo encarecidamente que realice una prueba comparativa controlada para descubrir qué camino es mejor para su proyecto en lugar de desperdiciar esfuerzos y arruinar la comunicación del equipo en debates "teóricos" infructuosos.

En uno de mis proyectos anteriores, perdimos el tiempo así durante más de un año hasta que decidimos hacer una prueba de este tipo. Primero, lo ejecutamos durante unos meses, rastreando cuidadosamente el tiempo invertido en la creación de sucursales de manera "establecida". Luego, pasamos unos meses ejecutando y siguiendo el enfoque "alternativo".

Después de completar nuestra comparación, simplemente estudiamos los resultados del seguimiento y elegimos la forma en que parecía que consumía menos esfuerzo (si la memoria nos sirve, teníamos un promedio de 4 por semana por desarrollador usando una manera versus 0.5 para de otra manera). Sin debates, sin sentimientos heridos, solo negocios. La gente obtiene números objetivos, compara y toma decisiones informadas, es así de simple.

  

Esto resultará difícil ... No puedo imaginar una forma objetiva de reconciliar esto.

Bueno, en nuestro caso no fue realmente difícil. Es probable que parezca difícil de la misma manera, ya que es difícil debatir las diferencias entre enfoques teóricos "teóricamente". Cuando se ejecuta la prueba real , todo este amplio material mágicamente se divide en casos de uso pequeños, concretos y manejables que son mucho más fáciles de evaluar mucho .

Las cosas que vale la pena tener en cuenta es que 1) los pocos meses mencionados anteriormente se demostraron suficientes para evaluar cuidadosamente los esfuerzos que se supone están relacionados con uno u otro enfoque y 2) mientras se realiza la prueba, es más Es importante simplemente escribir cuidadosamente las cosas, dejando que las discusiones se traten por separado. Fue como,

  • "Pasé una hora integrándome con un cambio de componente semicocido cometido por John"
    va al ticket etiquetado como branching-strategy-1
  • "Pasé una hora investigando el error introducido en la reciente fusión de Paul"
    va al ticket etiquetado como branching-strategy-2

Al final de la prueba, estos datos se "extraen" de rastreador de problemas , discutido y aclarado Los resultados se exportan a Excel, la diferencia se calcula y las preferencias se basan en eso.

Aquí es realmente importante que los compañeros de equipo registren cualquier cosa que parezca estar relacionada con tal vez , porque si no se registran, los datos que son importantes para quizás se perderán. A diferencia de eso, para los datos que se registra , no es difícil descartar lo que se considera irrelevante en una discusión más exhaustiva en el análisis retrospectivo.

  • ... Y sí, en nuestro ensayo, eliminamos algunos registros de esa manera, ... y no, no hubo un debate acalorado allí, porque 1) todo se trataba de discutir casos de uso reales, concretos, prácticos y materiales hasta el punto de sentirse bastante estrategia agnóstica . Y porque 2) el equipo estaba interesado en encontrar la forma en que ahorra nuestros esfuerzos por cosas más interesantes en lugar de en los debates religiosos sobre si ramificar o no ramificar .

Esto se parece en algo a una ley de Postel (también conocida como principio de robustez ),

  

sea conservador en lo que hace, sea liberal en lo que acepta de los demás

En cuanto a las situaciones en las que la bifurcación es una mala idea , bueno, al preparar la ejecución de prueba mencionada anteriormente, estudiamos la información disponible ( se resume en otra respuesta en Programadores ) - solo para descubrir si tal vez podamos evitar pasar unos meses en ejecutar las pruebas comparativas.

De lo que aprendimos en aquel entonces, la respuesta es "depende del proyecto":

  

no hay una "mejor" estrategia de ramificación acordada comúnmente aplicable a ningún proyecto

     
  • la mayoría de los recursos parecen estar de acuerdo en que elegir una estrategia productiva depende de los detalles específicos del proyecto

  •   
  • nota al margen. Según lo anterior, parece que cualquier cambio en la estrategia de bifurcación de proyectos debe ser probado, medido y comparado con otras opciones probadas ...

  •   
    
respondido por el gnat 16.01.2013 - 16:15
14

La pregunta es muy general. Puedo decir, con cierta seguridad, que SIEMPRE hay una situación en la que X es una mala idea, sin importar qué tan buena sea la idea de X.

Su compañero de trabajo se aferra a una vista que era NECESARIA en el pasado, cuando no existían buenas herramientas de combinación de control de fuente y combinación. Básicamente, no cree que la fusión pueda funcionar diariamente.

Hace menos de 5 años, trabajé con algunas personas que insistieron en bloquear las desprotecciones (tenía que retirar antes de editar, y solo una persona podía revisar un archivo a la vez) porque simplemente no podían entender que la fusión era posible y funcionó bien.

La pregunta es: ¿POR QUÉ su compañero de trabajo no cree en la fusión? He creído en él desde que lo vi por primera vez en CVS hace muchas lunas.

Mi conjetura es que hay algo en la forma en que está operando que está causando problemas de fusión, y su compañero de trabajo no puede ver que sea posible debido a algún problema operacional por parte de su equipo. Hasta que descubras qué es eso, nunca lo convencerás.

    
respondido por el Michael Kohne 16.01.2013 - 15:44
4

Mi experiencia personal con esto es que la capacitación ayudará en estos casos.

Tuve el mismo problema (con SVN) con los compañeros de trabajo. Después de capacitar a mis compañeros de trabajo, un grupo de proyecto (del cual no era miembro) solo se desarrolló en las sucursales y nunca en el tronco.

Lo más importante en el entrenamiento es que la fusión (y los conflictos durante eso) son normales y no son una excepción. Si sus compañeros de trabajo pierden el miedo de fusionarse y tener conflictos (porque esto es normal), después de algún tiempo, la situación debería aclararse.

    
respondido por el Uwe Plonus 16.01.2013 - 15:42
1

Bueno, más ramas implica más complejidad. Imagina que tu software crece, el equipo crece, el tiempo pasa ... Creo que el problema principal es lidiar con la fusión y los conflictos si las sucursales comienzan a divergir demasiado y la gente trabaja paralelamente en ellas.

Ejemplo estúpido: teníamos dos ramas grandes, con cambios en áreas superpuestas, y un tipo tuvo la súper idea inteligente de cambiar todas las pestañas a espacios en el maletero ... arrrrghh ... la fusión fue una pesadilla. En realidad, la herramienta de fusión ni siquiera lo hizo correctamente, por lo que al final, "no fusioné" miles de líneas una a una a mano.

Además, cuando pasa el tiempo, debes hacer un seguimiento de qué hay en qué, cuál está todavía activo, cuál no, si alguna rama permanece inactiva durante demasiado tiempo, se vuelve más difícil fusionar, o tal vez alguien se olvide una mini-solución al resolver un conflicto, etc.

Supongo que, al final, todo es una pregunta sobre el balance correcto. Haga una rama cuando lo necesite, pero no las haga "solo por diversión". También tendería a hacer más fácil una rama con Git o Mercurial que con SVN, son más fáciles y más flexibles cuando se trata de sucursales, mientras que SVN ha sido varias veces un PITA para mí. Así que supongo que también depende de lo que uses ... pero menos ramas generalmente hacen la vida más fácil.

    
respondido por el dagnelies 16.01.2013 - 15:58
1

Creo que has respondido tu propia pregunta

we have issues with merging. I argue the root cause of these issues are a lack team
communication and a lack of knowledge on how to correctly use our source control system 
to full effect (TFS).

Si su equipo no se está comunicando tan bien como podría tener código en sucursales o pequeños proyectos separados, realmente no importa. Dicho esto en sus comentarios, está hablando de darles a las personas la oportunidad de aprender más sobre esta herramienta / opción, y eso tiene que ser algo bueno. La bifurcación es como cualquier herramienta, puede ser realmente útil y también puede ser abusada.

En mi lugar actual, no utilizamos ramificaciones, no por elección principalmente porque somos muy pequeños, y hay muchas otras cosas que debemos poner en práctica primero. Si tuviéramos ramificaciones, podríamos escribir más parches, hacer más prototipos y fusionarnos de nuevo en la base del código principal.

Creo que la bifurcación podría causar un problema si se ignora y se le permite salir de las manos. Como todo lo que crece a través de las ramas, un poco de poda no hará ningún daño.

    
respondido por el Daniel Hollinrake 16.01.2013 - 16:52
1

Creo que el núcleo de la pregunta tiene que ver con la fusión, no con la ramificación. Creo que lo que le preocupa a su supervisor es volver a fusionarse (el caso más común así como también se deriva de su pregunta). Esto después de que git lo hizo fácil de fusionar ("NO IMPORTA LO FÁCIL DE ENTRAR, SÓLO LO FÁCIL DE MIRAR" - Lunus Torvalds), se ha propagado a la mayoría de los Sistemas de Control de Versiones.

El cerebro no ayuda pero regresa a experiencias anteriores. Parece que la última vez que su colega comprobó el problema, las soluciones disponibles no estaban en un buen nivel. Por lo tanto, ideó una solución alternativa (los mini proyectos) y se olvidó de verificar nuevamente, digamos cinco años después. Muy común, especialmente cuando las personas pasan a la gerencia media.

    
respondido por el Dimitrios Mistriotis 16.01.2013 - 17:12
0

Incluso las mejores ideas pueden ser llevadas a un extremo ridículo. Si bien la mayoría de los sistemas de control de versiones pueden manejar muchas ramas sin problemas, el problema se encuentra en el extremo humano, ya que se pierde en qué rama pertenece a quién, fue la rama en la que se trabajará más adelante o se desactivará, etc.

    
respondido por el Marcin 16.01.2013 - 15:46

Lea otras preguntas en las etiquetas