gitosi vs gitolite? [chiuso]


139

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:


191

Sto cercando l'installazione di un server Git per condividere progetti con il mio team.

Puoi semplicemente usare git.

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.

La soluzione senza installazione

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

Configurare un server git è facile.

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:

  • Installa git
  • Crea un utente di nome git
  • Aggiungere le chiavi pubbliche e della tua squadra per l'utente git .ssh/authorized_keysdi file
  • Cambia la shell dell'utente git in modo che sia git-shell
  • Creare repository sul server
  • avvia git pull / spingendo su git@yourserver.com

L' 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


13
Dopo aver installato la bestia che è GitLab + Gitolite, se non hai bisogno di un controllo accurato su progetti ecc., Questa è la strada da percorrere.
Andrew T Finnell,

Grazie per questa risposta! In realtà quando ho detto che non volevo creare account utente per ciascuno, avrei dovuto anche menzionare che non volevo che i miei utenti git avessero accesso alla shell del server tramite ssh. Con la tua soluzione penso che avrebbero accesso alla shell tramite l'utente "git", giusto?
Greydet,

2
@wsams: 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.
ThiefMaster

8
@ThiefMaster sta facendo un'ipotesi su cosa intendi dire, se inserisci repository nell'URL /home/git/per accedere a un progetto git@server:project.git.
AD

1
@wsams legge questa parte della risposta "Cambia la shell dell'utente git in git-shell".
fabspro,

142

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...


3
Uso Gitolite da oltre 3 anni. Non ho mai avuto problemi con esso. I nostri server di produzione e di gestione temporanea hanno accesso in sola lettura ai repository necessari. Ed è un lavoro facile condividere un progetto con altri team di sviluppo. Inoltre è facile da configurare se conosci già unix e git :)
complistico

La documentazione di Gitolite include confronti con alternative: gitolite.com/gitolite/gitolite.html#alt
Comandante di Quinn,

15

Solo un sidenote. Puoi anche usare Gerrit per le tue esigenze:

Revisione del codice Gerrit

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:

Controlli di accesso Gerrit

È possibile limitare la push per eventuali rami, tag o qualsiasi cosa si possa immaginare definita nel documento dei controlli di accesso.


8

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.


2

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 :

  • repository git
  • accesso a grana fine (afaik gitlab utilizza gitolite sotto il cofano)

se vuoi il metodo di installazione rapido e veloce: usa il programma di installazione di bitnami


Sì, ma GitLab (con gitlab-shell) ha perso tutti gli hook VREF che puoi facilmente configurare con Gitolite. E molte persone vorrebbero che tornassero: github.com/gitlabhq/gitlab-shell/issues/14 e github.com/gitlabhq/gitlab-shell/pull/85
VonC
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.