In 'branch by abstraction', come si dovrebbe fare la revisione del codice?

4

Il mio manager ha raccomandato di prendere in considerazione la tecnica di "ramificazione per astrazione" , in cui, anziché creare feature branch, più sviluppatori lavorano nello stesso ramo di controllo della versione e astraggono la funzionalità su cui stanno lavorando ad es usando i cavicchi delle funzioni.

Sono scettico riguardo a questo approccio, ma mi sento obbligato a considerare almeno una parvenza di equità. Una delle mie principali preoccupazioni riguarda la revisione del codice. Gli sviluppatori del mio team usano le richieste pull per esaminare il codice degli altri. Senza rami, questo approccio non sarebbe disponibile.

La mia domanda è, se si dovesse applicare questa tecnica, come potrebbe essere eseguita la revisione del codice (facilmente)?

    
posta micapam 21.01.2015 - 23:04
fonte

1 risposta

1

Il nostro team utilizza il sistema di revisione del codice Gerrit , in cui le recensioni si basano sui commit, anziché sulle filiali. La curva di apprendimento di Gerrit è superiore alle richieste di pull, ma crea una cronologia del commit molto più pulita e consente commenti molto dettagliati sul codice.

I nostri repository locali contengono ancora filiali, ma il 95% dei nostri commit finisce direttamente sul 'sviluppo "filiale .

Per funzionalità più grandi, laddove sono necessari cambiamenti significativi nella struttura del database o in caso di refactoring di impatto, utilizziamo comunque i branch delle caratteristiche.

    
risposta data 22.01.2015 - 11:02
fonte

Leggi altre domande sui tag