revisione del codice con git-flow e github

Con git e github regolari posso fare una revisione del codice semplicemente creando una richiesta pull del ramo della funzione su cui sto lavorando al ramo principale. Come farei le revisioni del codice con git-flow? Con un flusso di lavoro come "git flow feature finish`, sono confuso su dove avvenga effettivamente la revisione del codice e su come git-flow o git possano facilitare tale revisione.

Ci siamo imbattuti in questo preciso problema di recente. Ci piace molto git flow, poiché usa un buon livello semantico (usando lo stesso livello che usi nella discussione di gruppo: "Inizierò la caratteristica A" più di "Creerò un ramo, controllalo"), mentre git è un livello molto "di implementazione" (che è buono e utile anche, ma diverso).

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

La nostra soluzione attuale:

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

Ciò è coerente con la nostra pratica, con il rovescio della medaglia di dover eliminare noi stessi il ramo (poiché non eseguiamo la finitura del flusso). Il nostro prossimo passo sarà probabilmente quello di reimplementare alcune parti del flusso git (poiché si tratta principalmente di concatenare i comandi git) per tenerne conto (avendo la parte "pulizia" della finitura, senza l'unione).

Il processo che il team con cui lavoro utilizza per questo è il seguente:

1. Crea un ramo di funzionalità: git flow feature start module_1
2. Il codice viene aggiornato nel ramo della funzione
3. Man mano che vengono apportate modifiche, vengono inviate a GitHub (o una volta alla fine, se preferito)
4. Quando la funzione è completata, viene aperta una richiesta pull nel confronto di GitHub develope nel ramo della funzionemodule_1
5. Il team esamina la richiesta pull e fa commenti
6. Eventuali modifiche dalla richiesta pull vengono apportate al ramo della funzione
7. Una volta incorporate tutte le modifiche nel ramo della funzione, la sezione della funzione è terminata: git flow feature finish module_1
8. Il developramo viene trasferito a GitHub (GitHub contrassegnerà automaticamente la richiesta pull come chiusa / unita quando ciò accade)

Normalmente tutto questo processo viene eseguito dall'autore originale ma ciò non è richiesto. Chiunque nel nostro team può intervenire e raccogliere questo processo in qualsiasi momento. Tutto quello che devono fare è controllare il ramo delle caratteristiche e continuare con il processo. Chi mai git flow feature finish module_1eseguirà avrà il lusso del proprio ramo di funzionalità locale che viene eliminato, ma chiunque altro abbia verificato il ramo deve farlo manualmente se vuole usare qualcosa di simile git branch -D feature/module_1.

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

Se stai facendo recensioni di codice, supporrò che tu abbia un repository centrale che contiene il codice "ufficiale". Gli sviluppatori si spostano da e spingono verso questo repository centrale.

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

1. Lo sviluppatore apporta modifiche a qualsiasi ramo, si impegna a livello locale.
2. Lo sviluppatore invia tali modifiche a Gerrit.
3. Gerrit crea elementi di revisione che gli altri possono rivedere.
4. I peer esaminano il codice, commentano e accettano o rifiutano il commit.
5. Quando il commit è accettato, quindi Gerrit rende tali modifiche a disposizione per gli altri a tirare 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 altri sviluppatori vedono le modifiche inviate solo 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 git flow per creare una funzione , ma non finirla o fonderla.
2. Crea una richiesta pull , ma non unirla. Attendere che l'approvatore lasci un commento. Il commento è il marchio di approvazione.
3. Fare la fine flusso git . (L'approvatore o lo sviluppatore possono farlo, a seconda di ciò che il team ha concordato.) La richiesta pull verrà contrassegnata come unita su github. Devi ancora eliminare il ramo sull'origine.