2010-12-10 16 views
13

Vorrei forzare altri membri del team a non lavorare sul ramo master ma su un ramo di sviluppo. abbiamo un repository git centrale in cui spingiamo il nostro lavoro. Vorrei sapere se è possibile impedire agli utenti di apportare modifiche al ramo principale ma consentire solo a determinati utenti di farlo.git - blocca ramo principale per alcuni utenti?

mi piacerebbe avere la seguente "workflow"

  • sviluppo è sempre fatto solo con uno sviluppo ramo
  • il rilascio-manager è responsabile della branch master e solo lui è permesso di fondere roba da un ramo di sviluppo nel master e spingerlo al ramo principale sul repository centrale a.

È possibile e come posso ottenere questo risultato?

+0

Il controllo accessi è esternalizzato da git al sistema operativo su cui è in esecuzione il server. Se stai usando il tuo server, ti consiglio di installare gitosis: http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way – blueberryfields

+0

grazie, darò un'occhiata alla gitosi ... – aurora

+0

Ho pensato che è esattamente perché 'git' è distribuito, non è necessario controllare le autorizzazioni perché non esiste un repository 'condiviso'? In altre parole, qualsiasi membro del team che lavora al progetto lavorerà sulla propria copia del repository, ed è il manutentore che unisce i rami in un repository "master" (solo un nome per esso, da non confondere con il ramo principale). – amn

risposta

6

Vedere man githooks: nel repository condiviso, è possibile creare uno script $(git rev-parse --git-dir)/hooks/pre-receive o $(git rev-parse --git-dir)/hooks/update che verifica ciò che gli utenti stanno cercando di inviare a quali riferimenti. Git viene fornito con un hook di esempio update-paranoid che applica ACL per-ref.

+0

grazie ... i githook sembrano essere molto potenti. darò un'occhiata sia alla gitosi che ai githook – aurora

+0

Qualcuno potrebbe espandersi su questo? Ho guardato il '[update-paranoid] (http://git.kernel.org/cgit/git/git.git/tree/contrib/hooks/update-paranoid?id=HEAD)' gancio, ma io sono non sono sicuro di capire come sarebbe l'ACL per più utenti. È previsto che un utente abbia più voci per i committer autorizzati nella forma: 'committer = John Doe <[email protected]>', e questo potrebbe essere usato per utenti N come: ' committer = John Doe < [email protected]> committer = Utente2 <[email protected]> committer = Utente3 <[email protected]> ' ? – blong

+0

@ b.long: 'update-paranoid' si aspetta uno' users/$ {USER} .acl' all'interno di/vcs/acls.git' repo (non * this * repo) per ogni accesso SSH; all'interno di ciascuna, ci possono essere tante linee 'committer =' come desiderato. Ma probabilmente vorrai modificare o riscrivere lo script per tuo uso personale. – ephemient

1

Il mio approccio a basso livello sarebbe semplicemente quello di consentire all'RM di essere l'unico con chiavi SSH da inviare al repository che tutti gli altri utilizzano come riferimento principale. In questo modo, nessuno tranne la RM può spingere a padroneggiare - eppure tutti possono lavorare perché hanno i loro rami di sviluppo locale e gli sviluppatori possono condividere tra loro i rami che preferiscono.

Il prossimo passo è quello di fare un tester di pentole per le cose che andranno presto in master. Questo piatto viene normalmente chiamato next o dev. L'idea è che più impatto ha un ramo, più a lungo si cuoce prima di un'unione da padroneggiare. Questo dà al RM pieno controllo su quali rami dovrebbero laurearsi e dà ancora a tutti un heads-up.

+0

grazie. ho pensato anche a ssh e sarebbe stato abbastanza semplice da configurare. ma ho pensato che ci dovrebbero essere "migliori" modi ...? – aurora

Problemi correlati