Git work-flow per premessa incerta (in attesa di decisione)

Question

Git work-flow per premessa incerta (in attesa di decisione)

#1 da (5 voti)

4

Non sono abbastanza sicuro, come nominare il mio problema. Ma inizierò con il solito uso di git.

Lavoro come singolo sviluppatore su un repository git. Solitamente realizzo branch di feature da master e li unisco di nuovo in master, una volta terminata la funzionalità. Nel frattempo, un altro ramo di funzionalità è stato fuso in master, quindi rebase l'altro ramo su master, prima di unire.

Ha funzionato molto bene, fino a poco tempo fa. Una dipendenza che ho nel mio progetto, ha bisogno di un aggiornamento. Ma non è stato ancora deciso come verrà implementato questo aggiornamento. Ma posso simulare il nuovo comportamento abbastanza semplicemente.

Quindi mi sono ramificato dal master e ho simulato quella correzione. Pertanto, quando la correzione effettiva è disponibile e unita al master, tutte le modifiche sopra riportate possono essere reimpostate sul master. Ma la decisione su quella correzione è ancora in sospeso e le mie filiali si stanno accumulando:

* ee8d0ab (HEAD, featureTwo) 
* e659932 
* 27986c0 (featureOne) 
* f0011e6 
* d4187cf 
* 552e35a 
* 37d597f (simulatedFix) 
* e0eb3d0 (origin/master, master)
* b06583c 
* d295b3e

Sento che non va bene. Mi sembra di costruire un reparto. Immagina come sarebbe la funzione featureTen o featureTwenty.

Quali sono i possibili inconvenienti di questo metodo? E qual è il modo migliore per gestire questa situazione?

git workflows

posta Angelo.Hannes 07.04.2014 - 12:00

fonte

1 risposta

Leggi altre domande sui tag git workflows

Ereditarietà / domanda di progettazione OO Progettazione di un database con riferimenti circolari per il caso one-of-many

score 5 · Accepted Answer

Crea un nuovo ramo di sviluppo: chiamiamolo "dev-with-dep". Quel ramo sarà ridefinito rispetto al master, e tutti i rami delle feature che dipendono dalla nuova dipendenza saranno ridefiniti contro dev-with-dep e uniti in esso quando avranno finito.

Il ramo di aggiornamento delle dipendenze stesso sarà rebasato contro dev-with-dep (dopo che dev-with-dep è rebased rispetto a master, ofcourse) e si fonderà in esso ogni volta che raggiungerai uno stato che vuoi rebase negli altri rami di funzionalità.

Una volta che la dipendenza può essere unita al master lo fai tramite dev-with-dep (che contiene tutte le funzionalità che hai completato) le altre feature branch saranno nuovamente ridimensionate rispetto a master.

In questo modo non si ottiene una pila di rami feature finiti che attendono la dipendenza - tutti si attendono ordinatamente in dev-with-dep. Inoltre, poiché le funzioni che dipendono dall'aggiornamento delle dipendenze vengono unite in dev-with-dep al termine dell'operazione, è possibile risolvere i conflitti di unione tra di esse sin dall'unione. Ciò significa che se la caratteristica A viene unita e la caratteristica B non è:

Se sia A sia B non dipendono dalla nuova dipendenza - A viene unito in master e B esegue il rebase e risolve il conflitto.
Se A e B dipendono dalla nuova dipendenza, A viene unito a dev-with-dep e B esegue il rebase e risolve il conflitto.
Se A non dipende dalla nuova dipendenza, ma B fa - A è unito a master, dev-with-dep è rebased rispetto a master e B rebase againt dev-with-dep e risolve il conflitto.
Se A dipende dalla nuova dipendenza ma B non - nulla che puoi fare qui, dato che A è unito a dev-with-dep che B non può ancora accesso.

Ancora: non riesco a pensare a nessun metodo che ti permetta di risolvere l'ultimo caso in anticipo, quindi la mia soluzione rimane "ottimale".