recensione del codice con git-flow e github

Ci siamo imbattuti recentemente in questo preciso problema. Ci piace molto il flusso git, in quanto utilizza un buon livello di semantica (utilizzando lo stesso livello che si usa nella discussione di gruppo: "Inizierò la caratteristica A" più di "Creerò un ramo, checkout"), mentre git è un livello molto "di implementazione" (che è buono e utile anche, ma diverso).

Il problema che abbiamo è con git feature finish , poiché unisce il ramo allo sviluppo, mentre vogliamo che venga inviata una richiesta pull e (ciò è importante) unita dal revisore , non il committer, per sottolineare la proprietà del team.

La nostra soluzione attuale:

1. Qualcuno usa git flow per creare un branch di funzionalità
2. Al termine, crea una richiesta pull (usando github)
3. La revisione ha luogo, con potenziali ulteriori commit
4. La richiesta pull viene unita usando GitHub dal revisore .
5. Non c'è la finitura della funzionalità git flow (poiché il ramo è già unito)

Questo è coerente con la nostra pratica, con il rovescio della medaglia di richiedere di eliminare il ramo noi stessi (come noi non git flusso finale). Il nostro prossimo passo sarà probabilmente quello di reimplementare alcune parti del flusso git (dato che si tratta principalmente di concatenare comandi git) per tenerne conto (avendo la parte "pulitura" del finale, senza l'unione).

Il processo con il quale lavoro il team con cui faccio uso è il seguente:

1. Crea un ramo di funzionalità: git flow feature start module_1
2. Il codice viene aggiornato sul ramo della funzione
3. Quando le modifiche vengono confermate, vengono inviate a GitHub (o una volta alla fine, se preferisci)
4. Una volta completata la funzione, viene aperta una richiesta di pull in GitHub confrontando develop e il ramo di funzione module_1
5. Il team esamina la richiesta di pull e fa commenti
6. Eventuali modifiche dalla richiesta di pull vengono apportate al ramo di funzione
7. Una volta che tutte le modifiche sono state incorporate nel ramo della funzione, il ramo della funzione è finito: git flow feature finish module_1
8. Il ramo develop viene inviato a GitHub (GitHub contrassegnerà automaticamente la richiesta pull come chiusa / unita quando ciò accade)

Normalmente tutto questo processo è eseguito dall'autore originale ma non è richiesto. Chiunque nel nostro team può intervenire e prendere questo processo in qualsiasi momento. Tutto quello che devono fare è fare il checkout del ramo delle caratteristiche e continuare con il processo. Chiunque esegua git flow feature finish module_1 avrà il lusso del proprio ramo di funzionalità locale in fase di eliminazione, ma chiunque altro abbia estratto il ramo dovrà farlo manualmente se vuole utilizzare qualcosa come git branch -D feature/module_1 .

Per gli hotfix usiamo un approccio simile e creiamo la richiesta pull in GitHub prima di completare l'aggiornamento rapido.

Se stai facendo revisioni del codice, supporrò che tu abbia un repository centrale che contiene il codice "ufficiale". Gli sviluppatori ritirano e spingono verso questo repository centrale.

Quando usi Gerrit , Gerrit stesso diventa il repository centrale (ha server SSH e HTTP integrati che lascia che gli utenti interagiscano con esso praticamente nello stesso modo in cui lo sono già). Quando si utilizza Gerrit, il flusso di lavoro diventa:

1. Lo sviluppatore apporta modifiche su qualsiasi ramo, esegue il commit localmente.
2. Lo sviluppatore trasmette tali modifiche a Gerrit.
3. Gerrit crea elementi di revisione che altri possono esaminare.
4. I peer esaminano il codice, fanno commenti e accettano o rifiutano il commit.
5. Quando il commit è accettato, quindi Gerrit rende tali modifiche disponibili per gli altri da estrarre dal ramo.

Quando si utilizza un repository centrale, altri sviluppatori possono vedere le modifiche inviate dopo il passaggio 2. Gerrit introduce il flusso di lavoro di revisione del codice, quindi gli altri sviluppatori vedono solo le modifiche inviate dopo il passaggio 5.

Funziona bene con git-flow (o qualsiasi altro schema di ramificazione) perché Gerrit supporta la revisione delle modifiche apportate su qualsiasi ramo.

Ecco un altro suggerimento.

1. Esegui il normale processo di flusso Git per crea una funzione , ma non completarlo o unirlo.
2. Crea una richiesta di pull , ma non unirla. Attendi che l'approvatore lasci un commento. Il commento è il marchio di approvazione.
3. Completa il flusso git . (O il responsabile dell'approvazione o lo sviluppatore possono farlo, a seconda di quanto concordato dal team.) La richiesta di pull verrà contrassegnata come unita su github. Devi ancora eliminare il ramo sull'origine.