Manutenzione di due versioni software separate dallo stesso Codebase nel controllo versione

Invece di avere due versioni di codice con una base comune, dovresti progettare la tua applicazione in modo da rendere quelle funzionalità premium plug-in e guidate dalla configurazione piuttosto che da diverse basi di codice.

Se hai paura di spedire quelle funzionalità premium (disabilitate dalla configurazione) con la versione di base, puoi ancora rimuovere quel codice in una fase finale di costruzione / confezionamento e hai solo due profili di build.

Avendo questo design puoi anche spedire 5 diversi sapori e diventare molto flessibile, magari permettendo anche a terze parti di contribuire.

Raccomando vivamente non di utilizzare i rami per questo scopo. In generale, dovresti considerare i rami per le cose che saranno (o potrebbero essere) unite di nuovo insieme più tardi (o per i rami di rilascio, dove alla fine si fermerà lo sviluppo di uno dei rami). Nel tuo caso, non unirai mai le tue versioni "base" e "premium" insieme, e saranno entrambe mantenute indefinitamente, quindi le filiali non sono appropriate.

Invece, mantieni una versione comune del codice sorgente e usa la compilazione condizionale (ad esempio #ifdef in C / C ++, non sicuro quale sia l'equivalente per PHP) per includere o escludere le sezioni di codice che differiscono tra "base "e" premium ".

Sembra che PHP non abbia una funzione di compilazione condizionale incorporata, quindi potresti usare il preprocessore C ( cpp , probabilmente già lo hai) per preelaborare il tuo codice sorgente comune e da quello, produrre un "basic" "e una versione" premium "senza le direttive del preprocessore. Ovviamente, se scegli di farlo, dovresti usare make o qualcosa di simile per automatizzare il processo di esecuzione del preprocessore.

Utilizziamo 2 progetti separati, quello di base e quello Premium che dipende dal progetto di base. Non utilizzare le barre, in genere vengono utilizzate per le funzionalità.

Mentre le risposte più recenti sono a favore della compilazione condizionale invece delle filiali, c'è uno scenario in cui c'è un chiaro vantaggio nell'usare i rami: se tu (ora o più tardi) decidi di rendere disponibile il codice sorgente della versione base, includendo tutta la cronologia delle versioni ma escludendo tutte le funzionalità premium, puoi farlo con l'approccio dei rami ma non con un singolo ramo e una compilazione condizionale.

Suggerirei di evitare il cherry picking e invece di unire tutte le modifiche dalla versione di base alla versione premium. Non dovrebbero esserci funzionalità o correzioni di bug incluse nella versione base ma mancanti nella versione premium. Per rendere le cose il più indolori possibile, è necessario assicurarsi che il ramo premium modifichi il meno possibile i file comuni. Quindi il ramo premium dovrebbe contenere principalmente file aggiuntivi, e forse alcune leggere modifiche per costruire istruzioni. In questo modo, le modifiche dalla versione di base si fonderanno automaticamente senza causare conflitti.

La risposta di Greg suggeriva di "considerare i rami per le cose che saranno (o potrebbero essere) unite insieme di nuovo più tardi". Con l'approccio che ho appena descritto, è il caso, tranne che il ramo finale per tutti i commit sarà master-premium non master (che in realtà è master-basic ).

Naturalmente i sottomoduli sarebbero anche un'opzione. Dipende dal tuo processo di compilazione, ma se puoi rendere la versione premium in un progetto che usa la versione base come modulo, sarebbe perfetto. Potresti avere un periodo più difficile se ad un certo punto decidi di selezionare le funzioni dal ramo premium nel ramo base. Con i sottomoduli tale cambiamento sarebbe rappresentato come due commit distinti, mentre con i rami questo sarebbe un singolo commit alla versione base, e la successiva fusione nella versione premium saprebbe che questi cambiamenti sono già inclusi e non hanno da unire nuovamente.

In "hardware" questo viene fatto spesso, sono sistemi venduti per controllare il disordine, mi spiace non riesco a ricordare come sono chiamati.

Una volta che la lavatrice "mid range" viene spedita, il suo codice non cambia se non per una correzione di bug molto importante, anche quando lo stesso codice viene cambiato nella lavatrice "low end" che viene spedita alcuni mesi dopo. / p>

I clienti non si aspettano di ottenere aggiornamenti per una lavatrice che hanno già portato, un nuovo modello non viene spedito ogni pochi mesi.

La maggior parte di noi non vive in quel mondo, quindi fa ciò che dice Greg a meno che tu non stia scrivendo software per lavatrici.