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

Questo dipende dalla grandezza del cambiamento, ma non lo considererei una buona pratica per le differenze che hai descritto.

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

Se si hanno piccole modifiche, l'intero sforzo di fusione e mantenimento delle filiali sembra eccessivo rispetto al problema. Usa il tuo preprocessore o sistema di compilazione per differenziare tra le versioni. Un semplice #ifdef fa il trucco? Quindi non risolvere i problemi con git, è eccessivo.

Questo non è esattamente ciò che i rami servono. Si suppone che i rami siano percorsi secondari di breve-medio periodo verso la 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 impostare il processo di compilazione (hai una build automatizzata, giusto?) in modo che possa produrre sia edizione su richiesta (o tutte in una volta).

Dopotutto, vuoi mantenere una "singola fonte di verità"; con le filiali, dovrai duplicare del codice, ma non tutto, e alcune fusioni potrebbero infatti interrompere la configurazione.

Una soluzione, come hanno sottolineato le persone, è configurare il sistema di generazione per supportare diverse versioni.

Prenderò in considerazione l'implementazione come comando di attivazione e utilizzo di un file di configurazione. Meno devi costruire, meglio è.

Dai un'occhiata a questo sito

Penso che sia una buona idea, a patto di non poterlo fare all'interno di un ramo senza mettere in cluster il codice.
Preferirei essere in grado di tenerlo in un ramo e usare file localizzati e di configurazione, specialmente se dici che le differenze sono minori.
Un altro modo potrebbe essere diverse build, ad esempio il file di build racchiude file diversi per clienti diversi, ma posso anche vedere lo strumento di compilazione che controlla i vari rami. Mentre usi git direi senza trucchi reali. Una strategia di ramificazione potrebbe essere quella di svilupparsi su rami diversi per compiti diversi, registrarsi al 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 :

Utilizza diversi obiettivi di compilazione per creare diverse versioni del software. I target possono differire di

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

Questa pre-elaborazione può ovviamente includere il preprocessore C classico ma potrebbe anche comportare l'uso di un preprocessore personalizzato, un motore di template per costruire visualizzazioni personalizzate, ...

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

Userei le filiali solo per cambiamenti significativi, altrimenti finisci per aggiungere ogni piccola modifica a numerosi rami, che non è affatto divertente da fare ed è molto soggetta a errori, specialmente se lavori con più persone.

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

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

La soluzione con i tre diversi rami (per produzione, sviluppo e funzionalità) funziona davvero bene. Diciamo che hai scoperto qualche bug nel tuo codice di produzione, quindi puoi applicare una patch a quella quindi rilasciarla. Assicurati solo di non aggiungere alcuna funzionalità al ramo di produzione o eventuali modifiche importanti al ramo di produzione. Tu e il tuo team dovrete auto-disciplinare per non aggiungere nessuna delle principali modifiche alla vostra produzione. Il ramo di produzione dovrebbe essere solo per correzioni di bug minori che non garantiscono una modifica importante nel codice di produzione.