Ramo a lungo termine: quando e come unirlo?

4

Nel mio progetto capstone computer science, abbiamo un team di 5 persone che lavorano su varie cose per un'app Android per Pokemon come gioco multiplayer ( Github ). Una o due persone stanno lavorando per implementare il "motore di battaglia" per i giochi Pokemon (solo I generazione). Questa funzione ha molto da fare. Inizialmente avevamo un unico problema con circa 50 caselle di controllo da implementare. Da quando l'ho diviso in 12 problemi separati .

Tutti gli sviluppi su questo motore di battaglia sono in corso in un ramo chiamato match-api-integration . È una branca a lungo termine, perché potrebbe impiegarci diversi sprint per implementarla completamente. Per implementare una funzione specifica del motore, ci spostiamo al di fuori di match-api-integration , facciamo un po 'di lavoro, inviamo una richiesta di pull e quindi ci fondiamo nuovamente in match-api-integration quando viene approvata. Tuttavia, vogliamo il motore di battaglia più aggiornato per diverse altre sezioni di funzionalità per garantire che l'integrazione sia corretta tra l'interfaccia utente e i componenti di dati, ad esempio.

Poiché questo ramo è longevo, come dovremmo ottenere quelle funzioni aggiunte in altri rami di funzionalità? L'unione periodica delle altre feature branch ha funzionato durante lo sprint per fare in modo che il motore più aggiornato li ingombra con i messaggi unisci match-api-intgration in whatever-feature . Non è un affare grande , ma comunque ingombrante.

Questa è la pratica tipica per un tale ramo, o c'è qualche alternativa più appropriata a cui non abbiamo pensato?

Modifica : il duplicato proposto chiede in quale frequenza è possibile unire i rami di feature in un ramo principale, incompleto o completo. La mia domanda è chiedere come aggiornare i rami di funzionalità con il codice da ancora un ramo di funzione un altro che sembra essere un ramo a lungo termine. Anche il consiglio nel duplicato non si applica al mio scenario; "Unisci solo codice stabile" - ovviamente il codice nel ramo a lungo termine è stabile, ma come aggiornare molti altri rami che dipendono da esso è una domanda diversa da quella proposta nel duplicare.

    
posta Chris Cirefice 19.10.2016 - 18:43
fonte

2 risposte

4

In generale, se le persone lavorano su più filiali, penso che sia utile reintegrarsi nel ramo principale il più spesso possibile. Se hai una "grande" unione ogni pochi mesi (o anche ogni poche settimane) può diventare rapidamente molto doloroso e soggetto a errori (specialmente se stai facendo unioni tra più persone).

Inoltre strongmente incoraggiamo il re-baselining regolare (cioè che tutti si uniscono dal ramo principale alle loro filiali locali) per evitare che le filiali locali si allontanino troppo "fuori sincrono" con il ramo principale .

Ricorda che, anche per i sistemi molto ben architettati, è altamente improbabile che cambiamenti significativi ad altre parti del sistema non abbiano alcun effetto sul tuo ramo.

    
risposta data 19.10.2016 - 20:13
fonte
3

Questo è un flusso di lavoro git insolito per quanto ne so. Il tuo ramo di long-life match-api-integration sta essenzialmente dividendo la tua applicazione in due componenti separati, il che è dannoso perché vuoi che la copia di ogni sviluppatore del repository sia il più simile possibile.

Dai un'occhiata a git flow . Invece di avere un ramo separato per il "motore di battaglia", creerai solo rami separati per aggiungere funzionalità al motore di battaglia, come fai ora. Quando una funzionalità è completa, dovrai unire quelle modifiche in sviluppare , che tutti dovrebbero fondere giornalmente.

Inoltre, se non ti piace ingombrare la tua cronologia con commit di unione, puoi considerare ribadire , ma tieni presente che il rebasing è leggermente più complesso di una semplice fusione.

    
risposta data 19.10.2016 - 19:47
fonte

Leggi altre domande sui tag