Flusso di lavoro Git - probabilmente rami a lungo funzionamento per la versione futura

3

Sono un membro di un piccolo team che fa parte di un team più ampio di sviluppatori che lavorano con Git. Noi (il team più grande) abbiamo un ramo principale in un archivio centrale nel quale impegniamo il nostro lavoro per la prossima versione (chiamiamolo 1.0). Il team più piccolo è stato incaricato di sviluppare una funzione (aggiornando una esistente, in realtà) che non sarà disponibile nella versione 1.0, ma in una versione successiva (1.1). Mi chiedo come gestire lo sviluppo di questa funzionalità in Git. Ho esaminato diversi flussi di lavoro di Git ma non ne ho trovato uno che si adatti davvero.

In primo luogo, stiamo lavorando a questa funzione come una squadra, quindi ho pensato che sarebbe stato opportuno mantenere un ramo di funzionalità remoto nel repository centrale a cui ci spingeremo tutti e quindi unirmi con il ramo principale quando la funzione è fatta. Ma il rilascio di 1.0 potrebbe richiedere alcuni mesi e ciò significa che saremo isolati dal ramo principale per un lungo periodo, il che probabilmente renderebbe molto difficile l'integrazione nel main. Idealmente, vorrei spostare i cambiamenti da main al nostro branch di funzionalità giornaliere / settimanali (in modo da affrontare i conflitti all'inizio e non in una volta dopo diversi mesi) ma ho letto che non è consigliato in Git (a mio avviso, fusione dalla parte principale a un ramo di funzionalità o la ridefinizione di un ramo pubblico è sconsigliato.

Ho visto una domanda simile ma la risposta accettata dice semplicemente di non funzionare in questo modo. Poiché non sono io a decidere le nostre versioni, questa non è una soluzione che funziona per me. In relazione a questo, anche se penso che il codice sia stabile, non posso assegnarlo al main, perché il QA non ha il tempo di controllare la funzionalità per la versione 1.0 e le modifiche al codice potrebbero introdurre un bug. Conosco i test di regressione automatica e l'integrazione continua e sto spingendo strong per entrambi, ma al momento queste cose non sono possibili.

Qual è il modo migliore per gestirlo?

    
posta Michal Tenenberg 17.08.2016 - 12:09
fonte

2 risposte

1

Ciò che hai lasciato fuori dalla descrizione è se la nuova funzionalità richiede una revisione seria del codice esistente. Questo lo renderebbe un 2.0 piuttosto che un 1.1. Quindi assumerò che tu non lo stia facendo.

Il modo più intelligente per farlo è aggiornare continuamente il ramo della funzione con gli aggiornamenti al ramo principale. Questo colpirà presto i problemi di fusione e 1.1 non toccherà il ramo principale finché non sarà pronto. Il ramo principale continuerà a ricevere aggiornamenti minori mentre 1.1 è sviluppato. Sarà anche il ramo delle caratteristiche (1.1).

Non farlo non evita questi problemi. Li trasforma in un enorme mucchio di problemi che continui a rimandare fino alla fusione. Meglio affrontarli presto quando arrivano.

    
risposta data 17.08.2016 - 12:25
fonte
-1

Mentre lavori nei rami di funzionalità è buona norma aggiornarsi con il master.

Questo può essere ottenuto con due diversi metodi:

  • unisci nell'ultimo master git merge master

  • rebase rispetto all'ultimo master git rebase master

Il più delle volte trovo che rebase è il modo migliore perché quando ci sono conflitti vengono presentati nel modo più semplice per risolvere.

Spesso rifondare contro il master aggiornato è una pratica comune nei vari negozi in cui ho lavorato.

    
risposta data 17.08.2016 - 13:50
fonte

Leggi altre domande sui tag