Sto cercando l'installazione di un server Git per condividere progetti con il mio team. Non voglio creare un account utente sul server con accesso SSH per ogni sviluppatore che necessita di un accesso git. Sembra che ci siano due soluzioni simultanee che coprono questo problema: gitosi e gitolite.
Non sono riuscito a trovare alcun confronto tra entrambe le soluzioni. Quali sono le principali differenze tra loro? Ci sono altre soluzioni simili?
Risposte:
Sto cercando l'installazione di un server Git per condividere progetti con il mio team.
Per avere un server git l'unica cosa di cui hai bisogno sul server remoto è git. Se non hai bisogno di autorizzazioni precise (la condivisione solo con il tuo team suggerisce che è possibile) o eventuali funzionalità extra, non hai bisogno di gitolite o simili.
Se git è disponibile sul server remoto, puoi fare quello che stai chiedendo in questo momento, senza fare nulla
ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare
A livello locale:
cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master
Se vuoi fare cose con un utente git dedicato, i documenti per configurare un server git sono brevi, perché è davvero abbastanza facile da fare.
In sintesi:
.ssh/authorized_keysdi filegit-shellL' unica differenza tra l'uso di un utente git dedicato e non è che se si configura l'utente git per usarlo git-shell, non si permetterà di fare nient'altro. In termini di funzionamento come server git, tuttavia, è identico alla soluzione senza installazione
git push -u origin mastere git pushdopo puoi usarlo . Preferisco gito * perché a mio avviso nessuno che acceda a un repository dovrebbe preoccuparsi del percorso assoluto che ha sul sistema remoto.
/home/git/per accedere a un progetto git@server:project.git.
La differenza principale è che la gitosi è ormai obsoleta e non è più attivamente mantenuta.
Gitolite è molto più completo e ha appena rilasciato la sua terza versione .
La sua caratteristica più interessante è il riferimento virtuale (abbreviato in VREF) che ti consente di dichiarare tutti gli hook di aggiornamento che desideri, il che ti consente di limitare un push di:
nome dir / file :
supponi che non desideri che gli sviluppatori junior spingano le modifiche al Makefile, perché è piuttosto complesso:
- VREF/NAME/Makefile = @junior-devs
numero di nuovi file :
supponi che non desideri che gli sviluppatori junior eseguano il push di più di 9 file per commit, perché desideri che eseguano piccoli commit:
- VREF/COUNT/9/NEWFILES = @junior-devs
rilevamento avanzato del tipo di file : a
volte un file ha un'estensione standard (che non può essere 'gitignore'd), ma in realtà viene generato automaticamente. Ecco un modo per catturarlo:
- VREF/FILETYPE/AUTOGENERATED = @all
vedi src/VREF/FILETETYPEper vedere il meccanismo di rilevamento.
controllo dell'email dell'autore :
alcune persone vogliono assicurarsi che "puoi solo fare il push dei tuoi commit".
- VREF/EMAIL-CHECK = @all
Vedere src/VREF/EMAIL-CHECK.
voto su commit :
Un'implementazione di base del voto su un commit è sorprendentemente facile:
- VREF/EMAIL-CHECK = @all.
# 2 votes required to push master, but trusted devs don't have this restriction
# RW+ VREF/VOTES/2/master = @trusted-devs
# - VREF/VOTES/2/master = @devs
Vedi src/VREF/VOTESper l'implementazione.
e così via...
Solo un sidenote. Puoi anche usare Gerrit per le tue esigenze:
In primo luogo sembra che Gerrit sia utilizzato per la revisione del codice, ma è possibile utilizzarlo anche per la gestione degli utenti e fornire loro autorizzazioni ben definite. È possibile ignorare la revisione del codice (tramite i controlli di accesso ) e utilizzarlo solo per la gestione di progetti e ssh-keys. Gerrit ha un meccanismo di controllo degli accessi davvero forte:
È possibile limitare la push per eventuali rami, tag o qualsiasi cosa si possa immaginare definita nel documento dei controlli di accesso.
Per una soluzione ancora più rapida e sporca, basta usare git daemon e andare peer-to-peer. Ecco un articolo su come fare proprio questo.
Modifica: riconosco che questo non risponde rigorosamente alla domanda del PO. L'ho messo qui principalmente per quelli, come me, che si imbattono in questo mentre cercano un modo sporco e sporco di condividere il codice fino a quando non viene impostato un account github aziendale.
Sono stato per un po 'in giro per ottenere un server git che funziona con accesso LDAP, controllo di accesso a grana fine ecc ... Trovato una rivelazione: Usa Gitlab :
se vuoi il metodo di installazione rapido e veloce: usa il programma di installazione di bitnami