¿Es una buena práctica usar sucursales para mantener diferentes ediciones del mismo software?

66

Tenemos un producto que tiene algunas ediciones diferentes. Las diferencias son menores: diferentes cadenas aquí y allá, muy poca lógica adicional en una, muy poca diferencia en la lógica en la otra. Cuando se está desarrollando el software, la mayoría de los cambios deben agregarse a cada edición; sin embargo, hay algunos que no lo hacen y otros que necesitan ser diferentes. ¿Es un uso válido de las sucursales si tengo las sucursales release-editionA y release-editionB (..etc)? ¿Hay alguna trampa? ¿Buenas practicas?

Actualización: Gracias por la comprensión de todos, muchas respuestas buenas aquí. El consenso general parece ser que es una mala idea usar sucursales para este propósito. Para cualquiera que se lo pregunte, mi solución final al problema es externalizar cadenas como configuración y externalizar la lógica diferente como complementos o scripts.

    
pregunta Tamás Szelei 13.02.2012 - 09:18

8 respuestas

43

Esto depende de la magnitud del cambio, pero no lo consideraría una buena práctica por las diferencias que describió.

En general, desea que una rama Git sea algo que se fusionará en el futuro o que se almacene como solo lectura para referencia. Las ramas de Git que coexisten indefinidamente significan trabajo para todos: los cambios deben propagarse y fusionarse, los conflictos deben resolverse, toda la diversión. Si nada más, todos los desarrolladores deben recordar enviar cambios a cinco repositorios en lugar de uno.

Si tiene pequeños cambios, todo el esfuerzo de fusión y mantenimiento de las sucursales parece excesivo en comparación con el problema. Utilice su preprocesador o sistema de compilación para diferenciar entre versiones. ¿Un simple #ifdef hace el truco? Entonces no resuelvas problemas con git, es un exceso.

    
respondido por el thiton 13.02.2012 - 09:28
16

Eso no es realmente para lo que son las ramas. Se supone que las sucursales deben ser rutas cortas a mediano plazo a su línea de desarrollo, no versiones paralelas a largo plazo del mismo código.

Colocaría todas las diferentes versiones en la misma rama, con subdirectorios para las partes que son diferentes entre las ediciones, y configuré tu proceso de compilación (tienes una compilación automatizada, ¿no?) para que pueda generar cualquiera Edición bajo demanda (o todas ellas a la vez).

Después de todo, desea mantener una "fuente única de verdad"; con las ramas, estarás duplicando algún código, pero no todos, y ciertas fusiones de hecho romperían tu configuración.

    
respondido por el tdammers 13.02.2012 - 09:40
11

Una solución, como lo ha señalado la gente, es configurar el sistema de compilación para que sea compatible con diferentes ediciones.

También consideraría implementarlo como función alterna y usar un archivo de configuración. Cuanto menos tengas que construir, mejor.

Eche un vistazo a este sitio.

    
respondido por el Magnus 13.02.2012 - 11:05
3

Creo que es una buena idea, siempre que no pueda hacerlo dentro de una rama sin agrupar mucho el código.
Preferiría poder guardarlo en una rama y usar archivos localizados y de configuración, especialmente si dice que las diferencias son menores.
Otra forma podría ser diferentes compilaciones, por ejemplo, su archivo de compilación contiene diferentes archivos para diferentes clientes, pero también puedo ver la herramienta de compilación revisando diferentes sucursales. Como usas git, diría que no hay errores reales. Una estrategia de ramificación podría ser desarrollarse en diferentes ramas para diferentes tareas, registrarse en la rama maestra y fusionar de maestro a edición X e Y.

    
respondido por el Farmor 13.02.2012 - 09:27
2

Esto suena más como un trabajo para diferentes configuraciones de compilación. la respuesta de Thiton va en esta dirección pero lo llevaría mucho más lejos que #ifdef :

Use diferentes objetivos de compilación para compilar diferentes ediciones del software. Los objetivos pueden diferir por

  • la configuración que incluyen,
  • el objeto o los archivos de origen que incluyen, o
  • el preprocesamiento del código fuente.

Este preprocesamiento puede incluir obviamente el preprocesador C clásico, pero también podría implicar el uso de un preprocesador personalizado, un motor de plantillas para crear vistas personalizadas, ...

De esta manera, evita tener que forzar activamente todos los cambios a múltiples sucursales, lo que viola la SECA (por supuesto, también puede ser automatizado, pero no veo la ventaja).

    
respondido por el Konrad Rudolph 13.02.2012 - 14:06
1

Yo usaría sucursales solo para cambios significativos, de lo contrario terminas agregando cada cambio pequeño a numerosas sucursales, lo que no es nada divertido y es muy propenso a errores, especialmente si trabajas con más personas.

    
respondido por el John 13.02.2012 - 09:32
1

Si está lanzando todos ellos como productos diferentes, se recomienda tener múltiples sucursales. Si no, entonces todavía se recomienda usar algo como un tronco o una rama maestra.

Además, creo que esto dependería del proceso de desarrollo que tenga, particularmente de la implementación. Si tiene un proceso que solo permite que una rama se extienda a producción y las sucursales se tratan como "construcciones incrementales", lo que significa que la versión B no se puede implementar a producción a menos que la versión A se implementara primero, dado que todos los cambios de A ya están en B, entonces tener varias sucursales es el camino a seguir. Esto funcionará si tiene equipos dispersos por todo el mundo y normalmente tiene cambios ordenados por prioridad.

    
respondido por el setzamora 13.02.2012 - 10:15
-2

La solución con las tres ramas diferentes (para producción, desarrollo y características) funciona realmente bien. Digamos que descubres algún error en tu código de producción, luego puedes aplicar un parche para luego liberarlo. Solo asegúrese de no hacer ninguna adición de características a la rama de producción o cualquier cambio importante en la rama de producción. Usted y su equipo tendrán que autodisciplinar para no agregar cambios importantes a la función en su rama de producción. La rama de producción debe ser solo para correcciones de errores menores que no garantizan un cambio importante en su base de código de producción.

    
respondido por el ksinkar 13.02.2012 - 11:20

Lea otras preguntas en las etiquetas