Qual è la giusta convenzione di processo / denominazione con GitFlow per creare un sottoschede di un ramo di funzione?

Naviga le tue risposte
5

Sto usando GitFlow per le mie convenzioni di sviluppo. In generale, creo una user story e una funzione di abbinamento si distacca dal mio ramo di sviluppo e lavoro su quello. Una volta che la storia è completa, la funzionalità è completa e unita (rebased) di nuovo in sviluppo.

Tuttavia, ora sto riscontrando il problema in cui la mia funzionalità è piuttosto più epica. C'è una quantità significativa di sviluppo che sarà richiesta prima che la funzionalità (epic) possa essere consegnata (deve essere consegnata come un singolo deliverable). Ma lavorare solo in 1 feature branch non è appropriato.

Detto questo, qual è la convenzione appropriata per fare qualcosa del genere? Creo il mio ramo epico chiamato feature / MyEpicName e poi dico a tutti i miei sviluppatori di usare feature / MyEpicName come loro equivalente "sviluppo" ramo? Avrebbero quindi creato tutti i loro rami di funzionalità basati su quel ramo e unendo le loro modifiche a quel ramo.

Tuttavia, se seguo un processo del genere, la mia convenzione di denominazione inizia a diventare instabile. Normalmente (per convenzione), feature / xxxx implica un ramo di funzionalità dal ramo di sviluppo. Se i miei sviluppatori utilizzano la funzione / MyEpicName come ramo "di sviluppo", continueranno a creare la propria funzione / succursale. Ma poi diventa un caos gigantesco per cercare di capire quale caratteristica è derivata dallo sviluppo e che è ramificata dall'epica.

Esiste una convenzione / processo di denominazione accettabile per gestire questo tipo di situazioni? Chiamano la funzione di feature branch / MyEpicName / xxxxyyyy?

Il secondo interromperà alcuni degli strumenti / script? Es: gitflow hooks, smartgit, ecc.

    
posta Eric B. 24.11.2016 - 17:11
fonte

2 risposte

4

Per i rami di funzionalità usiamo la convenzione di nome-funzione / funzione. E.g riscrittura-citazione / funzione come il ramo caratteristica principale. La funzione di parola chiave qui è una convenzione utilizzata per segnalarlo come il ramo della funzione principale.

Le filiali saranno denominate come nome-funzionalità / nome subbranch. E.g rewrite-quote / quote-model

Il lato positivo di questo è facile vedere dove ogni ramo appartiene. Alcuni strumenti li raggruppano anche in una vista simile a una cartella (sourcetree)

    
risposta data 24.11.2016 - 17:55
fonte
2

Non ci sono convenzioni per questo. Forse perché i rami delle feature di lunga durata sono visti come Bad Thing (tm)

Se questa epica è la prossima versione del software, allora il ramo di sviluppo è il posto giusto per questo. le sue 'sub feature' sono feature branch, che crei nel solito modo e poi quando sono tutte fatte ti unisci a master e fai un rilascio.

Se hai dei deliverable che andranno in diretta PRIMA del completamento della tua epop, sarai costretto a unirli nuovamente nel tuo ramo epico, ritardandone così i progressi mentre hai integrato le modifiche, ripetuto di nuovo ecc.

Non credo che ci sia una soluzione a questa situazione. È possibile utilizzare i pulsanti di selezione delle funzioni per disattivare le funzioni non terminate e quindi attivarle tutte al termine dell'epica. Ma questo non è l'ideale, dato che avrai un lavoro incompiuto nel master.

L'approccio migliore secondo me è rivalutare l'epopea e dividerla in piccoli deliverable che è possibile completare nel normale ciclo di rilascio.

Ad esempio, puoi aggiornare il database con nuove tabelle anche se il livello API non le utilizza ancora? quindi il livello api anche se non è usato dal front-end, ecc. ecc

    
risposta data 24.11.2016 - 17:40
fonte

Leggi altre domande sui tag

Come posso scrivere un caso di test unitario per l'utilità di conversione del formato di file? Rompendo la grande classe in classi più piccole quando hanno bisogno di uno stato comune?