gitosi vs gitolite?

Sto cercando di installare un server Git per condividere i progetti con il mio team. Non voglio creare un account utente sul server con accesso SSH per ogni sviluppatore che ha bisogno 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?

Sto cercando di installare un server Git per condividere i 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 permessi a grana fine (la condivisione con solo il tuo team suggerisce che è ansible) o di altre funzioni extra, non hai bisogno di gitolite o simili.

La soluzione di non installazione

Se git è disponibile sul server remoto, puoi fare quello che stai chiedendo in questo momento, senza fare nulla

ssh [[email protected]]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 [[email protected]]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 facile da fare.

In sintesi:

  • Installa git
  • Crea un utente chiamato git
  • Aggiungi le tue e le chiavi pubbliche del tuo team al file .ssh/authorized_keys dell’utente git
  • Cambia la shell dell’utente git per essere git-shell
  • Creare repository sul server
  • avvia git pull / push su [email protected]

L’ unica differenza tra l’utilizzo di un utente git dedicato e non, è che se si installa l’utente git per usare git-shell , non si autorizza a fare nient’altro. Per quanto riguarda il funzionamento di git server, è identico alla soluzione di non installazione

La principale differenza è che la gitosi è ormai obsoleta e non viene più mantenuta triggersmente.

Gitolite ha molte più funzionalità complete e ha appena rilasciato la sua terza versione .

La sua caratteristica più interessante è il riferimento virtuale (VREF in breve) che consente di dichiarare il numero di hook di aggiornamento che si desidera, che consente di limitare una spinta:

  • dir / nome file :
    Di ‘che non vuoi che gli sviluppatori junior spingano le modifiche al Makefile, perché è piuttosto complesso:
    - VREF/NAME/Makefile = @junior-devs

  • numero di nuovi file :
    Supponiamo che tu non voglia che gli sviluppatori junior spingano più di 9 file per commit, perché vuoi 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 prenderlo:
    - VREF/FILETYPE/AUTOGENERATED = @all
    Vedi src/VREF/FILETETYPE per vedere il meccanismo di rilevamento.

  • controllando l’email dell’autore :
    Alcune persone vogliono assicurarsi che “puoi solo spingere i tuoi stessi commit”.
    - VREF/EMAIL-CHECK = @all
    Vedi src/VREF/EMAIL-CHECK .

  • votazione sul commit :
    Una implementazione di base del voto su un commit è sorprendentemente semplice:
    - 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/VOTES per l’implementazione.

  • e così via…

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

Gerrit Code Review

In primo luogo sembra che Gerrit sia utilizzato per la revisione del codice, ma è ansible utilizzarlo anche per la gestione degli utenti e fornire loro autorizzazioni ben definite. È ansible ignorare la revisione del codice (tramite i controlli di accesso ) e utilizzarla solo per gestire i progetti e le chiavi ssh. Gerrit ha un meccanismo di controllo degli accessi davvero forte:

Gerrit Access Controls

È ansible limitare a premere per eventuali rami, tag o qualsiasi cosa si possa immaginare definita nel documento dei controlli di accesso.

Per una soluzione ancora più rapida e più sporca, basta usare git daemon e andare peer-to-peer. Ecco un articolo su come fare proprio questo.

Modifica: Riconosco che questo non risponde in modo rigoroso alla domanda dell’OP. Metto questo qui principalmente per quelli, come me, che si imbattono in questo mentre cercano un modo sporco per condividere il codice fino a quando non viene creato un account github aziendale.

Ho fatto un po ‘di casino per far funzionare un server git con accesso LDAP, controllo di accesso a grana fine, ecc … Ho trovato una rivelazione: Usa Gitlab :

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

se vuoi il metodo di installazione rapido e veloce: usa l’ installer di bitnami