Come rivedere centinaia di commit e formalizzare le richieste di unione

Question

Come rivedere centinaia di commit e formalizzare le richieste di unione

#1 da (3 voti)

2

Al mio lavoro ogni riga di codice deve essere rivista e questa recensione è formalizzata in una richiesta di fusione.

Ora siamo di fronte a una situazione in cui uno sviluppatore ha sviluppato un prototipo per un nuovo prodotto che è ora in produzione. Ci sono alcune centinaia di commit e molte linee cambiate tutte in un ramo. Mi sto chiedendo quale sarebbe il modo migliore per rivedere il codice, formalizzarlo con la richiesta di unione e mantenere una cronologia relativamente pulita.

Ho pensato in due modi:

Il modo più semplice sarebbe rivedere tutto il codice esistente, fare una richiesta di unione e unire il ramo prototipo in master (o ramo di sviluppo). Questa soluzione richiederebbe del tempo prima di essere completata e potrebbe essere mentalmente impegnativa per i revisori, ma mantiene la cronologia git.
Un altro modo che ho pensato, sarebbe quello di rivedere componente per componente. In un nuovo ramo creiamo una nuova cronologia se commettiamo un componente ciascuno e facciamo più richieste di unione. Questa soluzione ci consente di vedere la progressione e la formalizzazione della convalida di ciascun componente (e non solo di una grossa fetta di lavoro), ma dovremmo scrivere una nuova cronologia git che potrebbe causare un problema di unione.

git code-reviews gitlab

posta Jason Marechal 11.09.2018 - 10:10

fonte

1 risposta

Leggi altre domande sui tag git code-reviews gitlab

Obiettivo C - messaggi annidati ... confusione su Modifica comportamento - Caso speciale in un ciclo

score 3 · Accepted Answer

Solo la via normale. Lo sviluppatore invia una richiesta di pull; sai dove questa richiesta di pull dovrebbe alla fine essere unita. Potrebbero esserci dei conflitti, in questo caso spetta allo sviluppatore risolvere questi conflitti e aggiornare la richiesta di pull.

Ora una differenza rispetto alle normali operazioni: poiché ti aspetti che questa richiesta di pull richieda molto tempo, chiedi ai tuoi colleghi sviluppatori di non unirsi a quel ramo fino a quando non viene eseguita la richiesta di pull, per evitare nuovi conflitti che devono essere uniti, invalidando il tuo revisione.

Quindi esegui una revisione, che richiederà un po 'di tempo e si unirà. La tua recensione può essere fatta in qualsiasi modo tu voglia. Un così grande cambiamento probabilmente non può essere rivisto fissando i diff. Un modo che funziona per me: crea due cartelle, una per il vecchio ramo, una per il ramo che dovrebbe essere unito. Totalmente fuori dal controllo git Usa uno strumento diff buono per spostare effettivamente le modifiche nel vecchio ramo. Come "Nuovo ramo aggiunto un file X", quindi aggiungo un file vuoto X al vecchio ramo. "Il file X contiene una nuova funzione f", quindi sposto quella funzione f al vecchio ramo ecc. Ovviamente non lo fai ciecamente, quando aggiungi la funzione f, è lì che la controlli.