Quello che stai cercando è probabilmente un ramo di accumulazione.
Se hai solo due rami - il ramo di sviluppo e la linea principale, e la linea principale è cambiata da quando è stato creato il ramo di sviluppo e non è stata fatta la fusione dalla linea principale al ramo di sviluppo durante il processo:
+------.----.------dev-------------------------...
/ / /
/ / /
+------------------mainline--------------------+
Quindi è solo una questione 'semplice' di fare un'altra unione dalla linea principale a dev, risolvendo l'unione in dev, e quindi unendola alla mainline (che dovrebbe avere avuto cambiamenti minimi tra due si fondono) e chiudono il ramo.
+------.-----.-----dev---.-----.+
/ / / / \
/ / / / \
+------------------mainline--------------------+
La chiave qui è che dovresti davvero evitare di avere una build rotta da mainline. La linea principale è nella maggior parte dei luoghi un "questo è buono" e da ciò che la gente si dirige. Se invece hai fatto solo un 'unione con la linea principale e la correzione':
+-----.-----.------dev----+
/ / / \ finally fixed
/ / / \ v
+------------------mainline--.---.---.---------+
È possibile che qualcuno abbia potuto diramarsi dallo stato rotto in mainline prima di quelli pronti e stabili. Questo è spesso visto come una cosa negativa.
Uno dei bit con questo che può causare qualche problema è che dopo lo sviluppo viene fatto sul ramo dev, il suo ruolo / politica cambia. Lo sviluppo avviene in un ramo dev ... ma dopo lo sviluppo, stai facendo qualcos'altro nel ramo dev. Questo va contro alcuni schemi di ramificazione . Non puoi usare questo modello, ma è qualcosa di cui essere consapevole e in considerazione.
Il caso precedente era quello semplice: un ramo dev. Ma cosa succede se hai due rami dev che devono essere riconciliati?
Indico Advanced SCM Branching Strategies di Stephen Vance (una buona lettura quando si parla di ramificazione e sistemi di controllo della versione centrale (piuttosto che distribuiti - sebbene se lo leggete potete sicuramente trovare dei paralleli tra questo documento e cose come git flow ).
Vance identifica ruoli specifici che un ramo può essere. Hai linea principale, sviluppo, manutenzione, accumulo e imballaggio. In questo caso, abbiamo a che fare con mainline, dev e infine con l'accumulo.
Il problema con il lavoro con due rami e il tentativo di unire la linea principale è che può renderlo ancora più disordinato per un periodo di tempo più lungo.
La soluzione è di introdurre un ramo di accumulo.
Nell'esempio precedente, anche il ruolo di accumulo faceva parte del ramo principale (che ha anche il ruolo principale). Sembrava questo:
Tuttavia,quandolecosesicomplicanoconl'unione,avereiruoliprincipaliediaccumulosulramoprincipalepuòportareaproblemi.Quindi,invece,creaunramodiaccumuloacuiunisciiramidisviluppochepossonoquindiesserericonciliatiericollegatiallalineaprincipale.Questaparticolareimmaginemostraancheunramodiimballaggio,maquestononèindiscussionequi.
Un aspetto importante da notare qui è che tutto si dirama dalla linea principale (non da qualche altro ramo), ha un ciclo di vita, si ricongiunge alla linea principale, e quindi è chiuso. Non ci sono rami di lunga durata (diversi dalla linea principale). Ogni ramo ha un ruolo specifico da soddisfare e quando questo è completo il ramo viene rimosso.