Flusso di lavoro revisione codice + feature Branching in TFS

Question

Stiamo iniziando a lavorare con i rami di funzionalità e vogliamo impostare una politica di check-in che consenta solo i check-in alla baseline quando hanno una revisione di codice associata.

Il nuovo flusso di lavoro di revisione del codice nel 2012 è piuttosto interessante, dal momento che è possibile interagire facilmente con lo sviluppatore e altri revisori e commentare direttamente le righe di codice. Tuttavia sembra che MS non ha pensato pienamente il caso d'uso perché abbiamo facilmente incorrere nel seguente problema:

1. Lo sviluppatore lavora la funzione ramo il check-in/scaffalature e in avanti integrando regolarmente.

2. Quando desidera integrare la funzione, si collega nuovamente alla linea di base e richiede una revisione di queste modifiche in sospeso.

3. Il revisore fa diversi commenti e ora deve cambiare un po 'di codice. Dove lo fa?

Opzione 1: Torna al ramo, modificare il codice e il check-nei cambiamenti nel ramo. Annullare le modifiche in sospeso della prima unione. Unisci e richiedi di nuovo una revisione. Ripeti fino a quando non ci sono più commenti. Check-in l'unione. Questo non è bello perché tutti i commenti di revisione sono nelle modifiche in sospeso dell'unione e lei deve lavorare sul ramo in cui non vede direttamente i commenti.

Opzione 2: Apportare le modifiche direttamente alle modifiche in sospeso dell'unione. Richiedi di nuovo una recensione. Ripeti fino a quando non ci sono più commenti. Check-in l'unione. Se vuole continuare a lavorare sul ramo, dovrebbe fare un'integrazione diretta perché le modifiche dalla revisione non sono presenti.

In entrambi i casi, la seconda recensione è sempre molto fastidiosa, perché non si ha modo di vedere solo i cambiamenti tra la prima e la seconda revisione, dal momento che si sta sempre diffondendo con la linea di base.

mi manca qualcosa qui? C'è un'altra opzione che consente di rivedere le modifiche da una recensione? Qualcuno ha un modo migliore di ramificare funzionalità e revisione del codice?

Nuovo:. Utilizzando VS e TFS2013, ancora nessun miglioramento :(

Answer 1

Non manca nulla Questo è un problema sfavorevole associato con il modo in cui Codice recensioni sono state implementate, possono essere collegate ad un solo changeset, non a un intervallo di modifiche

Se la tua squadra è abituata ad un'alta frequenza di check-in sui propri rami delle funzionalità, quindi avere ogni singolo changeset revisionato usando lo strumento potrebbe essere un sacco di spese generali. raccomandazione

C'è un trucco, non è l'ideale, ma può essere d'aiuto. Puoi controllare (sul tuo ramo delle funzionalità) tutti i file che sono stati modificati dall'ultimo check-in. Quindi richiedi una recensione. Creerà un set di scaffali con le tue modifiche e lo associerà alla recensione. In questo modo non è necessario eseguire l'unione prima di richiedere la revisione. Assicurati di unire l'ultima versione dalla principale alla sezione delle funzionalità prima di eseguire questa operazione.Esistono due svantaggi principali:

1. Mentre tutti i file modificati saranno collegati alla revisione, le modifiche dall'ultima revisione non verranno evidenziate automaticamente. Il revisore dovrebbe fare manualmente un "Confronta con la versione" e scegliere il target di confronto.
2. C'è un limite di 4000 (dalla cima della mia testa) file che possono essere associati a una revisione, in modo tale da porre un limite ai file che è possibile rivedere come gruppo (spero che non cambi 4000 + file tra le integrazioni nel main).