Flusso di lavoro di Gitlab, forzando la revisione del codice o unendo la richiesta sul ramo


18

Sto lavorando per implementare Gitlab nella mia azienda con una strategia di flusso di lavoro. La mia idea è che gli sviluppatori avranno accesso ai repository ma, ogni volta che provano a eseguire il commit, il loro codice deve essere rivisto.

So che posso farli creare una succursale prima di eseguire il commit e quindi creare una richiesta di unione dopo che è stata inviata al repository. Non sono ancora chiaro su certe cose ... L'idea che contiamo sulle persone per creare un ramo e quindi una richiesta di unione sembra difettosa, esiste una soluzione che forza una sorta di politica che il ramo principale può rimanere pulito a meno che un " admin "approva il codice che sta per fondersi in esso. Ho letto "flusso di lavoro del team github" ma non sembra offrire una soluzione praticabile. È gradito qualsiasi consiglio sul processo o sulla propria best practice. Grazie!


1
"The idea that we rely on people to create a branch and then a merge request seems faulty"Mi sembra che tu abbia un problema più grande della mancanza di funzionalità in un sistema di controllo della versione. Se si tratta solo di dedicare più tempo alla creazione di una filiale, dai un'occhiata a Atlassian Stash e alla sua integrazione con Jira.
toniedzwiedz,

5
Grazie Tom, la mia idea è di applicare una politica standard, sto eliminando la possibilità di errore
Mike,

2
Considera questo post di blog da gitlabhq about.gitlab.com/2014/09/29/gitlab-flow
spuder


Potresti farli usare le loro forcelle ....
Wildcard,

Risposte:


14

Ho iniziato a lavorare con gitlab, la lettura della sezione AIUTO fornisce un layout del flusso di lavoro. A questo punto, questa sembra essere la migliore soluzione alla mia domanda. Se qualcuno ha esperienza con questo flusso di lavoro o consigli, si prega di aggiungere ulteriori informazioni.

Dalla sezione AIUTO:

Flusso di lavoro

  1. Progetto clone
    git clone git@example.com:project-name.git
  2. Crea una filiale con la tua funzione
    git checkout -b $feature_name
  3. Scrivi il codice Effettua modifiche
    git commit -am "My feature is ready"
  4. Spingi il tuo ramo su GitLab
    git push origin $feature_name
  5. Rivedi il tuo codice nella pagina di commit
  6. Crea una richiesta di unione
  7. Il responsabile del team esaminerà il codice e lo unirà al ramo principale

Nella sezione commit del tuo repository, sei effettivamente in grado di proteggere i rami che costringono gli sviluppatori a seguire il processo sopra, creando un ramo e inoltrando una richiesta di unione.

Schermata - Protezione di un ramo


2
Esiste un modo per imporre questo flusso di lavoro (ad es. Utilizzando una filiale protetta) ma consentire a qualsiasi assegnatario (non solo team leader con privilegi di amministratore / master) di unire la richiesta?
Adam,

Ho appena provato ad assegnare una richiesta di unione a qualcuno senza privilegi di master e ottengono il seguente messaggio nella richiesta di unione. Questo non può essere unito automaticamente, anche se potrebbe essere unito non hai il permesso di farlo. Quindi, non sembra che sarebbero in grado di farlo.
Mike,

Grazie. Proverò il Review Board, Phabricator o Gerrit. Hai qualche esperienza con qualcuno di loro?
Adam,

No, scusa se non ho provato nessuno di questi servizi. Pubblica una risposta se hai successo.
Mike,

Certo, a meno che non lo dimentichi. A proposito, ho aggiunto Barkeep alla mia lista di controllo :)
Adam,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.