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

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.

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.

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.

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.

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).

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.

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.

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.