Scusate l'opera d'arte, so che sembra una navetta imperiale allungata, ma è il modo in cui visualizzo una strategia di controllo della versione di più team (o più stream). Il nucleo centrale, è il deposito del tronco (o master). Se ci sono molti più flussi puoi immaginare più piani che escono dal tronco, in cui varie ramificazioni e fusioni si svolgono all'interno di quei flussi (le linee più sottili).
La linea rossa mostra i pidocchi A dalla contabilità che vogliono prendere un pezzo di codice che B ob dal team di backup ha appena falsificato (ne ha bisogno urgentemente per alcuni motivo a cui non riesco a pensare). In realtà, non è come un cambiamento di linea che lei può solo fare da sola. Invece, puoi considerare che la contabilità è pesantemente bloccata e che è necessario un grande set di modifiche da Backup per continuare.
Ora, a quanto ho capito, questo è contro la best-practice, e le modifiche richieste dovrebbero passare attraverso il trunk, e Alice dovrebbe prenderle in questo modo, piuttosto che prendere la scorciatoia illustrata (un wormhole di controllo della versione). Tuttavia, sebbene l'abbia visto in vari punti, non ho mai visto ragioni profonde, lunghe e ben giustificate per le quali una fusione incrociata (o circolare?) È qualcosa da non consentire. L'unica cosa che posso pensare è che immagino possa portare a una maggiore risoluzione dei conflitti manuali.
Quindi le domande sono:
- Perché consentire l'unione di un flusso incrociato errato? (Ho bisogno di alcuni ben definiti motivi per convincere i miei colleghi che hanno una mentalità varia perché non dovrebbe essere fatto)
- Ci sono motivi giustificabili per andare contro la best practice?
- Che cosa succede se il team di Alice sta raggiungendo una scadenza di rilascio, può esserci un? eccezione?