Un breve riassunto di come gestiamo la gestione delle filiali : dal ramo MASTER possono essere create una o più sezioni di funzionalità (per lo sviluppo a medio-lungo termine), quando le modifiche implementabili sono state unite a MASTER quindi rilascia i rami. I rami di rilascio vengono mantenuti per mantenere la versione distribuita fino al rilascio successivo e vengono uniti a PRODUCTION per creare TAG distribuiti in Live Environments.
Primo versetto della domanda : è effettivamente necessario il passaggio del ramo PRODUCTION? Sicuramente TAGS può essere creato in modo affidabile da un ramo di rilascio nello stesso punto in cui sarebbe stato unito al ramo PRODUCTION?
Se vale la pena di avere il secondo verso della domanda : sarebbe un controllo sorgente adatto avere più di un ramo PRODUCTION pur avendo un solo MASTER?
La motivazione : presto avremo un progetto interno che inizierà (si spera) sarà un prodotto "white-label" che possiamo usare per sostituire tre applicazioni interne separate che usiamo attualmente (così come per eventuali future applicazioni). Sarebbe un back-end, una libreria, un'API ma tre team che lo utilizzano e gestiscono le proprie interfacce utente e aggiungono funzionalità riutilizzabili al back-end.
Un pensiero era che il progetto poteva essere un repo con un MASTER, vari rami di funzionalità per qualsiasi team in quanto hanno bisogno di sviluppare le cose (a medio-lungo termine). Ma dovremmo avere un ramo PRODUCTION per ciascuna delle tre "versioni" del prodotto o semplicemente TAG fuori dai rispettivi rami di rilascio? In modo che possano essere distribuiti indipendentemente dagli sprint e dai requisiti degli altri (a condizione che non infrangano l'infrastruttura condivisa).
PS: Ciascuna delle tre applicazioni viene distribuita in ambienti Live indipendenti e utilizzata da diversi reparti dell'azienda.
PPS: Se sei a conoscenza di altri flussi di versioning che sarebbero più adatti per favore dimmelo!
[EDIT - Dopo aver letto la risposta di jhr] Pensa a questo come a un grande progetto / applicazione. Ma invece di avere un team BIG che lavora sulle sezioni utilizzate da 3 dipartimenti (ciascuno con i propri flussi e caratteristiche dell'interfaccia utente richiesti, ecc.) Potremmo essere suddivisi in tre team, ognuno dei quali lavora sulle funzionalità di un reparto, sullo stesso codice base (repository) . Questa non è una domanda di specifiche tecniche, ma piuttosto una opinione, esperienza o preferenza ecc.