Funzioni rami, rami beta e funzionalità scartate

Penso che il flusso di lavoro nel suo nucleo sia soddisfacente e fondamentalmente segue le idee presentate qui: Un Git di successo modello di ramificazione . Tuttavia, penso che la ragione per cui si rompe per te è perché sei essenzialmente "fuori di testa" nel processo di fusione e test:

• I rami di funzionalità dovrebbero essere basati al di fuori del ramo di sviluppo anziché del ramo stabile / principale. Le funzionalità a lungo termine vengono continuamente ridefinite in cima al ramo di sviluppo.
• Le branch delle feature devono essere unite nel ramo di sviluppo solo quando sono pronte e approvate per la prossima release (vale a dire quando saranno unite, passeranno sicuramente alla prossima versione.)
• Durante la preparazione di una nuova versione, un ramo di rilascio viene rimosso dal ramo di sviluppo in cui viene eseguito il test finale prima di essere fuso nel ramo stabile / principale per la produzione.

Le cose diventano un po 'più complicate quando una funzione dipende da un'altra caratteristica non ancora fusa nello sviluppo, ma come Doc Brown menziona nel suo answer , penso che" toggle di funzionalità "sia una buona idea qui. Le funzionalità quasi completate sono unite nello sviluppo, ma disabilitate per l'uso di produzione. Le funzionalità dipendenti vengono quindi reimpostate all'inizio dello sviluppo e unite quando sono pronte.

Penso che rimuovere una funzione già integrata dopo un'unione sia difficile con la maggior parte dei VCS (o DVCS), quindi dovresti assicurarti che questa situazione si verifichi il più raramente possibile. Alcune idee:

• Se si dispone di una funzione per cui è in gioco l'approvazione (ad esempio, è necessario prima un test di usabilità prima di essere sicuri di creare la cosa "giusta"), assicurarsi che i tester lo facciano. prova già con una versione dal ramo della funzione, prima integrandola nel ramo di sviluppo. Quindi puoi evitare l'integrazione se la funzione è in gioco

• Secondo la mia esperienza, le sezioni di piccole dimensioni presentano un rischio minore di essere scartate o ritardate rispetto a quelle grandi, poiché è possibile renderle molto più semplici e veloci. Quindi cerca di rendere le fette delle feature più piccole possibile.

• Se hai una feature più complessa, composta da una dozzina (o più) sezioni di feature, e vuoi che l'utente finale veda questa caratteristica complessa solo come tutto-o-niente, presenta attrezzi di funzionalità nel tuo codice e utilizza un ramo di funzionalità per ogni sezione, non per l'intero oggetto. Questo in realtà non rende più facile "smontare" qualsiasi codice di funzionalità in seguito, ma se, ad esempio, dopo l'integrazione di metà delle sezioni di funzionalità nel ramo dev, qualcuno decide di non completare l'intera operazione per la prossima versione, è possibile lascia le feature feature rifinite nel ramo dev, senza attivare il commutatore di funzionalità. Quindi i tuoi utenti non noteranno che c'è una funzione completata a metà lì dentro.

EDIT: Se sei veramente interessato al "smantellamento" di un elemento in un momento nel quale parti di esso sono state integrate nel ramo dev e sono confuse con altri changeset, hai la possibilità di usare un ramo di funzione separato (o dovrei dire "ramo simile a una caratteristica"?) per quell'attività. Si modifica e / o si eliminano le parti rilevanti del codice all'interno di quel ramo, lo sviluppatore testarlo e quindi integrare nuovamente tale gruppo di modifiche nel ramo dev.

EDIT2: leggi questo post del blog di Martin Fowler per ulteriori informazioni sui pulsanti di attivazione.