¿Te sientes cómodo fusionando el código?

Question

Esta mañana, leí dos opiniones sobre refactorización.

• Opinión 1 (Página no está presente)
• dictamen 2 (Página no está presente)

Recomiendan ramificación (y posteriormente la fusión) código para:

1. Mantener el tronco limpio .
2. Permita que un desarrollador se aleje de los cambios de riesgo.

En mi experiencia (particularmente con StarTeam de Borland), la fusión es una operación no trival. Y por esa razón, me bifurco solo cuando debo (es decir, cuando quiero congelar un candidato de lanzamiento).

En teoría, la ramificación tiene sentido, pero la mecánica de fusión hace que sea una operación muy arriesgada.

Mis preguntas:

• ¿Se siente cómodo código de fusión?
• ¿Tiene un código de sucursal por razones distintas a la congelación de un lanzamiento candidato?

Answer 1

algunos principios rectores sueltas:

• Branch tarde y sólo cuando es necesario
• Combinar temprano y con frecuencia
• Recibe la persona adecuada para hacer la fusión, ya sea la persona que hizo los cambios o la persona que escribió la versión original es la mejor

La ramificación es solo otra herramienta, debe aprender a usarla efectivamente si desea el máximo beneficio.

Su actitud hacia la bifurcación probablemente difiera entre los proyectos distribuidos de código abierto (como los de Git) y los proyectos de desarrollo de su empresa (posiblemente en SVN). Para los proyectos distribuidos, querrá fomentar la ramificación para maximizar la innovación y la experimentación, para la última variedad querrá un control más estricto y dictará políticas de registro para cada línea de código que dicte cuándo debe o no producirse una bifurcación, principalmente para "proteger" el código.

Aquí es una guía de ramificación:
http://www.vance.com/steve/perforce/Branching_Strategies.html

aquí hay una guía más corto con algunas de las mejores prácticas de alto nivel:
https://www.perforce.com/sites/default/files/pdf/high-level-perforce-best-practices.pdf

Answer 2

Utilizamos svn. Solo nos lleva unos 5 minutos codificar la sucursal. Es trivial en comparación con la cantidad de dolor que nos ahorra de estropear el tronco.

Answer 3

Uso Subversion y considero la bifurcación muy simple y fácil. Entonces para responder la pregunta 1 ... Sí.

El motivo de la bifurcación puede variar enormemente. Bifurco si siento que debería. Muy difícil de poner reglas y razones para todas las posibilidades.

Sin embargo, en cuanto a "Permitir que un desarrollador se aleje de los cambios de riesgo". comentario. Estoy totalmente de acuerdo con eso. Creo una rama cada vez que quiero jugar con el código y me gustaría ser el único desarrollador trabajando en ello ... Cuando se bifurca, puede hacerlo ...

Answer 4

La ramificación puede ser dolorosa pero no debería t ser

Eso es lo que los proyectos de git-like (mercurial, bazar) nos dicen sobre CVS y SVN. En git y mercurial, la ramificación es fácil. En SVN es fácil, pero con grandes proyectos puede ser un poco difícil de manejar (debido al tiempo dedicado al proceso de bifurcación/fusión que puede ser muy largo, comparado con otros como git y mercurial, y difícil si no hay -conflictos obvios). Eso no ayuda a los usuarios que no están acostumbrados a la bifurcación a menudo a tener confianza en la bifurcación. Muchos usuarios que desconocen los poderosos usos de las ramificaciones simplemente lo mantienen alejado para no agregar nuevos problemas a sus proyectos, dejando que el miedo a lo desconocido los aleje de la eficiencia.

La ramificación debería ser una herramienta fácil y poderosa que tendríamos que usar por cualquier razón lo suficientemente buena como para ramificar.

algunas buenas razones para filiales:

• que trabajan en una característica específica en paralelo con otras personas (o mientras se trabaja en otras características, alternativamente, si estás solo en el proyecto);
• teniendo varias versiones de marca de la aplicación;
• teniendo versiones paralelas de la misma aplicación - como las técnicas simultáneas desarrolladas en el mismo tiempo por parte del equipo para ver qué funciona mejor;
• teniendo recursos de la aplicación que se cambian en una rama específica del artista/diseñadores (por ejemplo en juegos) donde la aplicación es "estable" mientras que otras ramas y troncales se usan para la adición y depuración de características;
• [agregar aquí usos útiles]

Answer 5

ramificación es trivial. Fusionar no es Por esa razón, raramente ramificamos cualquier cosa.

Answer 6

El problema de la bifurcación es la razón por la que uso un sistema de control de versiones distribuidas (Git en mi caso, pero también Mercurial y Bazar) donde la creación de una sucursal es trivial.

Uso ramas de corta vida todo el tiempo para el desarrollo. Esto me permite meterme en mi propio repositorio, cometer errores y malas elecciones, y luego rebase los cambios en la rama principal, por lo que solo se guardan los cambios limpios en el historial.

Utilizo tag s para marcar el código congelado, y es fácil en estos sistemas volver atrás y ramificarlos para corregir errores sin tener una carga de ramas de larga vida en la base de código.

Answer 7

Utilizamos svn y hemos adoptado una regla para los cambios de salto de rama. Los cambios menores se hacen directamente en el maletero.

También lanzamos versiones.

La ramificación y la fusión nos han funcionado. De acuerdo, hay momentos en los que tenemos que sentarnos a pensar cómo encajan las cosas, pero normalmente svn hace un gran trabajo fusionando todo.

Answer 8

Usando SVN, he encontrado que la ramificación es relativamente indolora. Especialmente si fusiona periódicamente el tronco en su rama para evitar que se desincronice demasiado.

Answer 9

Uso svn, el código de bifurcación tarda menos de un minuto. Solía ​​usar Clearcase, tardé menos de un minuto en codificar la sucursal. También utilicé otros SCM menores y no admitían ramas o eran muy dolorosos de usar. Starteam suena como este último.

Por lo tanto, si no puede migrar a una más útil (en realidad, solo he oído cosas malas sobre Starteam), entonces puede que tenga que probar un enfoque diferente: la ramificación manual. Esto implica verificar su código, copiarlo en un directorio diferente y luego agregarlo como un nuevo directorio. Cuando necesite fusionarse, deberá consultar ambos directorios y usar WinMerge para realizar la combinación, verificando los resultados en el directorio original. Torpe y potencialmente difícil si continúas usando la rama, pero funciona.

El truco con Branching no es tratarlo como un producto completamente nuevo. Es una sucursal, un dispositivo relativamente efímero que se utiliza para realizar cambios por separado y de forma segura en el tronco de un producto principal.Cualquiera que piense que fusionarse es difícil está refaccionando tanto los archivos de códigos (es decir, están renombrando, copiando, creando nuevos, eliminando viejos) que la rama se vuelve algo completamente diferente, o mantienen la rama tan larga que los cambios acumulados poco parecido al original. Puede mantener una sucursal durante mucho tiempo, solo tiene que fusionar sus cambios con regularidad. Haga esto y la bifurcación/fusión se vuelve muy fácil.

Answer 10

He estado en un proyecto usando svn y TFS y la bifurcación en sí misma es algo realmente simple.

Utilizamos la bifurcación para la versión candidata, así como para características duraderas o experimentales y para aislar las interferencias de otros equipos.

El único momento doloroso en la bifurcación es la fusión, ya que una rama antigua o intensamente desarrollada puede diferir mucho del tronco y puede requerir un esfuerzo significativo para fusionarse.

Habiendo dicho lo anterior, yo diría que la ramificación es una práctica poderosa y útil que debe tenerse en cuenta durante el desarrollo.

Answer 11

Solo lo he hecho un par de veces, así que no me siento cómodo con eso.

Lo hice para llevar a cabo experimentos de diseño que abarcarían algunos checkins, por lo que la bifurcación es una manera fácil de tapar usted mismo un jardín para jugar. Además, me permitió jugar mientras otras personas trabajaban en el rama, por lo que no perdimos mucho tiempo.

También lo he hecho al hacer cambios de gran alcance que harían que el baúl no sea accesible. Se hizo evidente en mi proyecto que tendría que eliminar la seguridad del tipo de tiempo de compilación para una gran parte de la base de código (pasar de genéricos a system.object). Sabía que esto tomaría un tiempo y requeriría cambios en toda la base del código que interferirían con el trabajo de otras personas. También rompería la construcción hasta que estuviera completo. Así que me ramifiqué y eliminé los genéricos, trabajando hasta que esa rama compilara. Luego lo fusioné nuevamente en el baúl.

Esto resultó bastante bien. Impidió una gran cantidad de pasos, lo cual fue genial. Esperemos que nada como esto vuelva a aparecer. Es raro que cambie un diseño que requiera este tipo de modificaciones de gran alcance que no den lugar a una gran cantidad de código que se descarta ...

Answer 12

Los ramificados deben gestionarse correctamente para facilitar la fusión. En mi experiencia (con Perforce) la integración regular a la sucursal desde la línea principal significaba que la integración de regreso a la línea principal transcurría sin problemas.

Hubo pocas ocasiones en que la fusión falló. La integración constante desde la línea principal hasta la sucursal bien pudo haber involucrado fusiones, pero solo eran pequeñas ediciones que las herramientas automáticas podían manejar sin intervención humana. Esto significaba que el usuario no "veía" que esto sucedía.

Por lo tanto, las fusiones necesarias en la integración final a menudo se pueden manejar automáticamente también.

Las herramientas de combinación de 3 vías fueron de gran ayuda cuando realmente se necesitaban.

Answer 13

¿Se siente cómodo código de ramificación?

Realmente depende de la herramienta que estoy usando. Con Starteam, la bifurcación es de hecho no trivial (TBH, Starteam apesta a la ramificación). Con Git, la bifurcación es una actividad regular y es muy fácil.

¿Tiene un código de sucursal por razones distintas de la congelación de un candidato de publicación?

Bueno, esto realmente depende de su patrón de control de versiones, pero la respuesta corta es sí. En realidad, le sugiero que lea los siguientes artículos:

• Version Control for Multiple Agile Teams por Henrik Kniberg
• FeatureBranch por Martin Fowler

me gusta mucho el patrón descrito en el primer artículo y se puede aplicar con cualquier (no distribuido) Sistema de control de versiones, incluido Starteam.

podría considerar el segundo enfoque (en realidad, una mezcla de las estrategias de ambos) con (y sólo con) unos sistemas distribuidos de control de versiones (DVCS) como Git, Mercurial ...

Answer 14

Trabajando en una base de código de millones de líneas de código con cientos de desarrolladores que se ramifican es una ocurrencia cotidiana. La vida de la sucursal varía según la cantidad de trabajo que se realiza.

Para un pequeño arreglo:

• diseñador hace una rama lateral de la corriente principal
• hace cambios
• pruebas
• opiniones
• fusiona cambios acumulados de corriente principal de rama lateral
• itera a través de uno o más de los pasos anteriores
• funde de nuevo a la corriente principal

Para una función de varias personas del equipo:

• equipo hace una rama lateral característica de la corriente principal
• miembro del equipo opera en función de rama lateral como en "pequeño arreglo "se acerca y se fusiona para contar con sidebranch.
• rama lateral primer periódicamente fusiona acumula cambios de corriente principal para ofrecer rama lateral. Pequeñas fusiones incrementales de la corriente principal para caracterizar la rama lateral son mucho más fáciles de tratar.
• cuando característica funciona, lo combinación definitiva de la corriente principal para ofrecer rama lateral
• función de combinación de rama lateral a la corriente principal

Para una versión de software del cliente:

• hacer una rama de lanzamiento
• entregar correcciones según sea necesario para liberar rama
• revisiones son propogated a/de la corriente principal como sea necesario

corrientes versión para el cliente pueden ser muy caros de mantener. Requiere recursos de prueba: personas y equipos. Después de un año o dos, el conocimiento del desarrollador sobre transmisiones específicas comienza a quedar obsoleto a medida que la transmisión principal avanza.

¿Puede usted imaginar la cantidad que debe costar para Microsoft para apoyar XP, Vista y Windows 7 al mismo tiempo? Piense en los bancos de pruebas, la administración, la documentación, el servicio al cliente y, finalmente, los equipos de desarrolladores.

Regla de oro: Nunca rompa la secuencia principal ya que puede detener a un gran número de desarrolladores. $$$

Answer 15

Usamos StarTeam y solo ramificamos cuando tenemos una situación que lo requiera (es decir, revisión de la producción durante el ciclo de lanzamiento o algún proyecto de largo alcance que abarca múltiples ventanas de lanzamiento). Usamos View Labels para identificar lanzamientos y eso hace que sea una tarea simple crear ramas más tarde según sea necesario. Todas las construcciones se basan en estas etiquetas de vista y no construimos código no etiquetado.

desarrolladores deben estar siguiendo un "código - comprometerse - prueba" modelo y si necesitan una vista para algunos fines de prueba o desarrollo "de riesgo" que crean y manejan. Administro el repositorio y creo ramas solo cuando las necesitamos.Esos tiempos son (pero no limitados a):

• de revisión Producción
• Proyectos con largos ciclos de desarrollo o superpuestas
• Amplia reescritura o desarrollo experimental

La herramienta de combinación en StarTeam no es el mejor, pero aún no me he encontrado con un problema causado por él. Quien está haciendo la fusión solo necesita estar MUY seguro de que saben lo que están haciendo.

Crear una vista de "Referencia de solo lectura" en Star Team y configurarla en una configuración flotante permitirá que los cambios en la línea externa se muestren automáticamente en la rama. Establecer elementos para bifurcar en el cambio. Esto es bueno para los esfuerzos de desarrollo concurrentes.

Crear una vista de "Referencia de solo lectura" con una configuración etiquetada es lo que usaría para las correcciones a versiones de producción existentes (suponiendo que las haya etiquetado).

Answer 16

La ramificación es trivial, ya que la mayoría ha respondido, pero la fusión, como dices, no lo es.

Las claves reales son desacoplamiento y pruebas unitarias. Intente desacoplar antes de bifurcar, y vigile la tubería principal para asegurarse de que se mantienen el desacoplamiento y la interfaz. De esta manera, cuando llega el momento de fusionarse, es como reemplazar una pieza de lego: quitar la pieza vieja, y la nueva pieza se adapta perfectamente a su lugar. Las pruebas unitarias están ahí para asegurar que nada se rompa.

Answer 17

Si la fusión es demasiado dolorosa, considere migrar a un mejor VCS. Eso será un dolor más grande, pero solo una vez.

Answer 18

La ramificación y la fusión deben ser bastante sencillas.

• Me siento muy cómodo ramificación/fusión.
• ramificación se hace por diferentes razones, dependiendo del modelo de proceso de desarrollo/

Hay algunos modelos rama diferente:

Aquí es una pregunta

Trunk   
    .  
    .  
    .  
    ..   
    . ....  
    . ... 
    .  ..Release1 
    .  
    .  
    ...   
    . .... 
    . ...Release2 
    .  
    .  
    ..   
    . ... 
    . .. 
    . ...Release3 
    .  
    .  

Ahora aquí está una cosa curiosa. Supongamos que Release1 necesita alguna corrección de errores. Ahora necesita ramificar Release1 para desarrollar 1.1. Eso está bien, porque ahora puede ramificar R1, hacer su trabajo, y luego fusionar de nuevo a R1 para formar R1.1. ¿Observe cómo esto mantiene los diffs claros entre lanzamientos?

Otro modelo de bifurcación es tener todo el desarrollo realizado en el Troncal, y cada versión se etiqueta, pero no se realiza ningún otro desarrollo en esa versión en particular. Las ramas suceden para el desarrollo.

Trunk           
    .               
    .               
    .               
    .Release1   
    .      
    .      
    .     
    .     
    .Release2   
    .     
    .......     
    .  ......  
    .   ...DevVer1 
    .   .  
    .   .    
    .  ...DevVer2 
    .  ....   
    . ....    
    ...      
    .Release3   
     . 

Puede haber uno o dos otros modelos de ramas principales, no puedo recordarlos en la parte superior de mi cabeza.

En resumen, su VCS debe admitir la bifurcación flexible y la fusión. Los sistemas VCS por archivo presentan un gran dolor IMO (RCS, Clearcase, CVS). SVN se dice que es una molestia aquí también, no estoy seguro de por qué.

Mercurial hace un gran trabajo aquí, al igual que (creo) git.