Mantener dos versiones de software separadas del mismo código de base en el control de versiones

En lugar de tener una versión de dos códigos con una base común, debe diseñar su aplicación de manera que esas características premium se puedan conectar y manejar por configuración en lugar de diferentes bases de código.

Si tiene miedo de enviar esas características premium (deshabilitadas por la configuración) con la versión básica, aún puede eliminar ese código en un paso final de compilación / empaquetado y solo tiene dos perfiles de compilación.

Al tener este diseño, también puede enviar 5 sabores diferentes y ser muy flexible, tal vez incluso permitiendo que terceros contribuyan.

Recomiendo encarecidamente a no usar ramas para este propósito. En general, debe considerar las ramas para las cosas que serán (o podrían ser) fusionadas de nuevo más tarde (o para liberar ramas, donde finalmente se detiene el desarrollo de una de las ramas). En su caso, nunca fusionará sus versiones "básica" y "premium", y ambas se mantendrán indefinidamente, por lo que las sucursales no son apropiadas.

En su lugar, mantenga una versión común del código fuente y use la compilación condicional (por ejemplo, #ifdef en C / C ++, no estoy seguro de cuál es el equivalente para PHP) para incluir o excluir las secciones de código que difieren entre "básico "y" premium ".

Parece que PHP podría no tener una función de compilación condicional incorporada, por lo que podría usar el preprocesador de C ( cpp , probablemente ya lo tenga) para preprocesar su código fuente común y, a partir de ahí, producir un "y una versión" premium "sin las directivas de preprocesador. Por supuesto, si elige hacer esto, debe usar make o algo similar para automatizar el proceso de ejecución del preprocesador.

Estamos usando 2 proyectos separados, el Básico y el Premium que depende del proyecto Básico. No use braches, normalmente se usan para funciones.

Si bien la mayoría de las respuestas actuales están a favor de la compilación condicional en lugar de las sucursales, hay un escenario en el que hay un claro beneficio al usar las sucursales: si (ahora o más tarde) decide que el código fuente de la versión básica esté disponible, Incluyendo todo el historial de versiones, pero excluyendo todas las funciones premium, entonces puede hacerlo con el enfoque de ramas pero no con una única rama y compilación condicional.

Yo recomendaría no elegir, y en su lugar fusionaría todos los cambios de la versión básica a la versión premium. No debe haber ninguna característica o corrección de errores incluida en la versión básica, pero falta en la versión premium. Para hacer que las cosas sean lo menos dolorosas posible, debe asegurarse de que la rama premium modifique los archivos comunes lo menos posible. Por lo tanto, la rama premium debería contener principalmente archivos adicionales, y quizás algunas modificaciones leves a las instrucciones de construcción. De esa manera, los cambios de la versión básica se fusionarán automáticamente sin causar conflictos.

La respuesta de Greg sugirió que “consideres las ramas para cosas que serán (o podrían ser) fusionadas de nuevo de nuevo más tarde". Con el enfoque que acabo de describir, este es el caso, excepto que la rama final para todas las confirmaciones será master-premium no master (que en realidad es master-basic ).

Por supuesto, los submódulos también serían una opción. Depende de su proceso de compilación, pero si puede convertir la versión premium en un proyecto que use la versión básica como un módulo, estaría bien. Sin embargo, es posible que tenga más dificultades si en algún momento decide elegir las características de la rama premium en la rama básica. Con los submódulos, tal cambio se representaría como dos compromisos distintos, mientras que con las sucursales sería un solo compromiso con la versión básica, y la siguiente fusión con la versión premium sabría que estos cambios ya están incluidos y no tienen para ser fusionado de nuevo.

En "hardware", esto se hace a menudo, se venden sistemas para controlar el desorden, lo siento, no puedo recordar cómo se llaman.

Una vez que la lavadora de "rango medio" se despacha, el código no cambia más que por una corrección de errores muy importante, incluso cuando se cambia el mismo código en la lavadora de "gama baja" que se envía unos meses más tarde.

Los clientes no esperan obtener actualizaciones de una lavadora que ya han traído, tampoco se envía un nuevo modelo cada pocos meses.

La mayoría de nosotros no vivimos en ese mundo, así que haz lo que dice Greg a menos que estés escribiendo software para lavadoras.