È buona norma utilizzare le filiali per mantenere diverse edizioni dello stesso software?

Abbiamo un prodotto che ha alcune edizioni diverse. Le differenze sono minori: stringhe diverse qua e là, pochissima logica aggiuntiva in una, pochissima differenza nella logica nell'altra. Quando viene sviluppato il software, è necessario aggiungere la maggior parte delle modifiche a ogni edizione; tuttavia, ci sono alcuni che non lo fanno e alcuni che devono differire. È un uso valido delle filiali se ho filiali release-editionA e release-editionB (..etc)? Ci sono dei gotcha? Buone abitudini?

Aggiornamento: grazie per la comprensione di tutti, molte buone risposte qui. Il consenso generale sembra essere che sia una cattiva idea usare i rami per questo scopo. Per chiunque si chieda, la mia soluzione finale al problema è esternalizzare le stringhe come configurazione ed esternalizzare la diversa logica come plugin o script.

Questo dipende dall'entità del cambiamento, ma non lo considero una buona pratica per le differenze che hai descritto.

In genere, si desidera che un ramo Git sia qualcosa che verrà unito in futuro o memorizzato in sola lettura per riferimento. I rami Git che coesistono indefinitamente significano lavoro per tutti: i cambiamenti devono essere propagati e uniti, i conflitti risolti, tutto il divertimento. Se non altro, ogni sviluppatore deve ricordare di inviare le modifiche a cinque repository anziché a uno.

Se si hanno piccole modifiche, l'intero sforzo di fusione e gestione dei rami sembra eccessivo rispetto al problema. Utilizzare il preprocessore o il sistema di generazione per distinguere tra le versioni. Un semplice #ifdeffa il trucco? Quindi non risolvere i problemi con Git, è eccessivo.

Questo non è davvero ciò che i rami sono per. Le filiali dovrebbero essere percorsi secondari di breve o medio termine verso la tua linea di sviluppo, non versioni parallele a lungo termine dello stesso codice.

Metterei tutte le diverse versioni nello stesso ramo, con una sottodirectory per le parti che sono diverse tra le edizioni e imposterò il tuo processo di compilazione (hai una build automatizzata, giusto?) In modo che possa produrre entrambe le versioni su richiesta (o tutti contemporaneamente).

Dopotutto, vuoi mantenere una "singola fonte di verità"; con i rami, duplicherai un po 'di codice, ma non tutti, e alcune fusioni in realtà infrangerebbero la tua configurazione.

Una soluzione - come hanno sottolineato le persone - è configurare il sistema di compilazione per supportare diverse edizioni.

Vorrei anche prendere in considerazione l'implementazione come funzioni di commutazione e utilizzare un file di configurazione. Meno devi costruire, meglio è.

Dai un'occhiata a questo sito.

Penso che sia una buona idea, a condizione che non sia possibile farlo all'interno di un ramo senza raggruppare troppo il codice.
Preferirei essere in grado di tenerlo in un ramo e utilizzare file localizzati e di configurazione, soprattutto se dici che le differenze sono minori.
Un altro modo potrebbe essere build diverse, ad esempio il file di build comprime file diversi per clienti diversi, ma posso anche vedere lo strumento di build che controlla diversi rami. Mentre usi git direi che non ci sono veri gotchas. Una strategia di ramificazione potrebbe essere quella di sviluppare su rami diversi per compiti diversi, effettuare il check-in nel ramo master e unire da master a editionX e Y.

Sembra più un lavoro per diverse configurazioni di build. la risposta di thiton va in questa direzione ma la prenderei molto più lontano di #ifdef:

Utilizzare obiettivi di build diversi per creare diverse edizioni del software. Gli obiettivi possono differire per

• la configurazione che includono,
• l'oggetto o i file di origine che includono, o
• la preelaborazione del codice sorgente.

Questa preelaborazione può ovviamente includere il classico preprocessore C ma potrebbe anche comportare l'utilizzo di un preprocessore personalizzato, un motore di template per creare viste personalizzate, ...

In questo modo, eviti di dover spingere attivamente ogni singola modifica verso più rami, il che viola DRY (ovviamente anche quello può essere automatizzato ma non vedo il vantaggio).

Userei i rami solo per cambiamenti significativi, altrimenti finirai per aggiungere ogni piccolo cambiamento a numerosi rami, il che non è affatto divertente da fare ed è molto soggetto a errori, specialmente se lavori con più persone.

Se li rilasci tutti come prodotti diversi, si consiglia di avere più filiali. In caso contrario, si consiglia comunque di utilizzare qualcosa come un tronco o un ramo principale.

Inoltre, penso che ciò dipenderebbe dal processo di sviluppo che hai, in particolare dalla distribuzione. Se si dispone di un processo che consente di distribuire un solo ramo alla produzione e i rami vengono trattati come "build incrementali", il che significa che la versione B non può essere distribuita alla produzione a meno che la versione A non sia stata distribuita per prima, dato che tutte le modifiche di A sono già in B, quindi avere più rami è la strada da percorrere. Questo funzionerà se hai squadre sparse in tutto il mondo e di solito hai le modifiche ordinate per priorità.

La soluzione con i tre diversi rami (per produzione, sviluppo e funzionalità) funziona davvero bene. Diciamo che scopri qualche bug nel tuo codice di produzione, quindi puoi applicare una patch e rilasciarlo. Assicurati solo di non apportare alcuna aggiunta di funzionalità al ramo di produzione o modifiche importanti al ramo di produzione. Tu e il tuo team dovrete autodisciplina per non aggiungere importanti modifiche alle funzionalità al vostro ramo di produzione. Il ramo di produzione dovrebbe essere solo per correzioni di bug minori che non garantiscono un cambiamento importante nella base di codice di produzione.