Ho un repository Git su un server di gestione temporanea a cui più sviluppatori devono poter attingere. git-initsembra avere una bandiera molto vicina a quello che sto cercando:, --sharedtranne che vorrei che più persone attirassero anche quel repository. La git-clone's --sharedbandiera fa qualcosa di completamente diverso.

Qual è il modo più semplice per modificare le autorizzazioni di un repository esistente?

Le autorizzazioni sono un parassita.

Fondamentalmente, è necessario assicurarsi che tutti quegli sviluppatori possano scrivere su tutto nel repository git.

Passa a The New-Wave Solution per il metodo superiore di concessione di capacità di scrittura a un gruppo di sviluppatori.

La soluzione standard

Se metti tutti gli sviluppatori in un gruppo appositamente creato, in linea di principio puoi semplicemente:

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

Quindi modificare il umaskper gli utenti in 002, in modo che i nuovi file vengano creati con autorizzazioni scrivibili in gruppo.

I problemi con questo sono legione; se siete su una distro che assume una umaskdi 022(come quello di avere un comune usersgruppo che include tutti di default), questo può aprire problemi di sicurezza altrove. E prima o poi, qualcosa rovinerà il tuo schema di autorizzazioni accuratamente predisposto, mettendo fuori uso il repository fino a quando non avrai rootaccesso e risolverlo (ad esempio, eseguendo nuovamente i comandi sopra).

La soluzione New Wave

Una soluzione superiore, sebbene meno ben compresa e che richiede un po 'più di supporto OS / tool, è quella di utilizzare gli attributi estesi POSIX. Sono venuto in quest'area solo di recente, quindi la mia conoscenza qui non è così calda come potrebbe essere. Ma fondamentalmente, un ACL esteso è la possibilità di impostare autorizzazioni su più dei 3 slot predefiniti (utente / gruppo / altro).

Quindi, ancora una volta, crea il tuo gruppo, quindi esegui:

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

Questo imposta l'ACL esteso per il gruppo in modo che i membri del gruppo possano leggere / scrivere / accedere a qualsiasi file sia già presente (la prima riga); quindi, dire anche a tutte le directory esistenti che ai nuovi file dovrebbe essere applicato lo stesso ACL (la seconda riga).

Spero che ti porti sulla buona strada.

se hai creato il repository (o clonato un nuovo repository nudo da uno esistente) con

$ git init --shared=group 

o

$ git init --shared=0NNN

Si suppone che Git gestisca le autorizzazioni al di là di ciò che fornisce umask predefinito. Finalmente questo è vero sulla mia versione di Git (1.6.3). Naturalmente questo presuppone che i tuoi utenti appartengano allo stesso gruppo.

Se avessi bisogno della gestione degli utenti in più gruppi con vari gradi di lettura / scrittura, però, andrei con la gitosi. Ho anche sentito parlare di gitolite ( http://github.com/sitaramc/gitolite ), un fork di gitosi che dovrebbe fornire autorizzazioni a livello di filiale, ma non posso dire che l'ho usato tutti personalmente però.

Questo non è stato detto, quindi voglio aggiungerlo rapidamente.

Per assicurarsi che i problemi con i permessi non si sfaldino, assicurati di impostare quanto segue sul file di configurazione del tuo repository condiviso git:

[core]
    sharedRepository = true

Ciò garantirà il rispetto delle impostazioni "umask" del sistema.

Il Manuale dell'utente di Git descrive come condividere un repository in diversi modi.

• Esportazione tramite Git Daemon .
• Esportazione tramite HTTP .
• Stile CVS / SVN, un singolo repository condiviso in cui gli sviluppatori spingono / tirano.

I modi più complicati, sebbene ricchi di funzionalità, per condividere i repository sono:

• Gitosis
• GitHub (o installazione del firewall GitHub )

Usiamo GitHub per un team di 6 sviluppatori.

Guarda anche gitolite per ospitare il tuo repository git. Apparentemente la gitosi non viene più sviluppata.

Un modo per correggere le autorizzazioni nel repository condiviso, in modo che gli utenti non abbiano problemi di autorizzazione quando spingono, è quello di creare uno script hook post-aggiornamento che farà proprio questo. Questo dovrebbe funzionare in qualsiasi versione di git.

Supponiamo di avere un repository condiviso in /myrepo.git. Tutti i file in quel repository appartengono a mysharedgroup . Tutti gli utenti che spingono verso quel repository dovrebbero appartenere anche a mysharedgroup . Ora crea il seguente file (cambiando mysharedgroup alle tue preferenze):

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null

Per aggregare i pezzi di buoni consigli dalle varie altre risposte e commenti sull'impostazione di un nuovo repository:

Se si sta impostando un nuovo repo myrepoin /srv/gitper il gruppo mygroup, questo è ciò che si vuole:

mkdir /srv/git/myrepo.git
chgrp mygroup /srv/git/myrepo.git
git init --bare --shared /srv/git/myrepo.git

1. la prima riga crea la directory repo
2. la seconda riga imposta il suo gruppo su mygroup
3. la terza riga inizializza un repository nudo con la seguente configurazione:
   1. core.bare = true: rendilo un repository nudo
   2. core.sharedrepository = 1(uguale a core.sharedrepository = group): la directory di repository e tutte le directory create successivamente saranno gestite da git per consentire le autorizzazioni di mygrouplettura, scrittura ed esecuzione (anche con il bit sgid impostato - in modo da lavorare con utenti per i quali mygroupnon è loro gruppo primario)
   3. receive.denyNonFastforwards = 1: nega push non in avanti veloce al repository

Se vuoi mettere a punto le autorizzazioni dell'utente, del gruppo o di altri utenti, usa --shared=0NNN, dove NNNsono l'utente standard, il gruppo e altri bit per i file (i bit di esecuzione e sgid nelle directory saranno gestiti in modo appropriato da git). Ad esempio, ciò consente l'accesso in lettura e scrittura all'utente e l'accesso in sola lettura al gruppo (e nessun accesso ad altri):

git init --bare --shared=0640 /srv/git/myrepo.git

Ciò consente l'accesso in lettura e scrittura all'utente e al gruppo (e nessun accesso ad altri):

git init --bare --shared=0660 /srv/git/myrepo.git

Ciò consente l'accesso in lettura e scrittura all'utente e al gruppo e l'accesso in sola lettura ad altri:

git init --bare --shared=0664 /srv/git/myrepo.git

Si noti che se non si consente l'accesso in scrittura al gruppo, assicurarsi di utilizzare prima chownper impostare il proprietario del repository, quindi eseguire il git initcomando come tale utente (per assicurarsi che il repository sia inizializzato con il proprietario corretto per tutti i file e le sottodirectory iniziali).

Puoi usare git-daemon per condividere il repository. Leggi la documentazione per git-daemon per maggiori informazioni.

MODIFICARE:

Controlla anche questo articolo 8 modi per condividere il tuo repository git .

Fare esattamente questo ha funzionato per me, per un repository esistente. Questo richiede consigli da diverse risposte e commenti prima:

Dalla directory principale del repository, sul server:

chgrp -R <whatever group> gitrepo
chmod -R g+wX gitrepo
cd gitrepo
find . -type d -exec chmod g+s {} +
git config core.sharedRepository group

La risposta di @stevek_mcc è quella che stavo cercando quando ho cercato su Google questa domanda

git clone --config core.sharedRepository=true