gitosis vs gitolite?

Estou procurando instalar um servidor git para compartilhar projetos com minha equipe. Eu não quero criar uma conta de usuário no servidor com access SSH para cada desenvolvedor que precisa de um access ao git. Parece que há duas soluções concorrentes que cobrem esse problema: gitosite e gitólito.

Não consegui encontrar nenhuma comparação entre as duas soluções. Quais são as principais diferenças entre eles? Existem outras soluções semelhantes?

    Estou procurando instalar um servidor git para compartilhar projetos com minha equipe.

    Você pode simplesmente usar o git.

    Para ter um servidor git, a única coisa que você precisa no servidor remoto é o git. Se você não precisa de permissions refinadas (compartilhar com apenas a sua equipe sugere que é uma possibilidade) ou quaisquer resources extras, você não precisa de gitolite ou similar.

    A solução sem instalação

    Se o git estiver disponível no servidor remoto, você pode fazer o que está perguntando agora, sem fazer nada

    ssh [user@]server cd repos/are/here/ mkdir project.git cd project.git git init --bare 

    Localmente:

     cd projects/are/here/project git remote add origin [user@]server:repos/are/here/project.git git push -u origin master 

    Configurar um servidor git é fácil.

    Se você quer fazer coisas com um usuário git dedicado, os documentos para configurar um servidor git são curtos – porque é bem fácil de fazer.

    Em suma:

    • Instalar git
    • Crie um usuário chamado git
    • Adicione as chaves públicas da sua e da sua equipe ao arquivo .ssh/authorized_keys do usuário git
    • Mude o shell do usuário do git-shell para ser git-shell
    • Criar repos no servidor
    • inicie o git pull / pushing to git@yourserver.com

    A única diferença entre usar um usuário git dedicado e não, é que se você configurar o usuário git para usar o git-shell ele não permitirá a si mesmo fazer qualquer outra coisa. Em termos de agir como um servidor git, é idêntico à solução no-install

    A principal diferença é que a gitose é agora obsoleta e não mais mantida ativamente.

    Gitolite é muito mais completo , e acaba de lançar sua terceira versão .

    Sua característica mais interessante é a Referência Virtual (VREF abreviada), que permite declarar quantos hook de atualização você quiser, o que permite restringir um push por:

    • nome do diretório / arquivo :
      Digamos que você não queira que os desenvolvedores juniores promovam mudanças no Makefile, porque é bastante complexo:
      - VREF/NAME/Makefile = @junior-devs

    • número de novos arquivos :
      Digamos que você não queira que desenvolvedores juniores empurrem mais de 9 arquivos por commit, porque você quer que eles façam pequenos commits:
      - VREF/COUNT/9/NEWFILES = @junior-devs

    • detecção avançada de tipo de arquivo :
      Às vezes, um arquivo tem uma extensão padrão (que não pode ser ‘gitignore’d’), mas na verdade é gerado automaticamente. Aqui está uma maneira de pegá-lo:
      - VREF/FILETYPE/AUTOGENERATED = @all
      Veja src/VREF/FILETETYPE para ver o mecanismo de detecção.

    • verificando o email do autor :
      Algumas pessoas querem garantir que “você só pode enviar seus próprios commits”.
      - VREF/EMAIL-CHECK = @all
      Veja src/VREF/EMAIL-CHECK .

    • votar em comete :
      Uma implementação básica da votação em um commit é surpreendentemente fácil:
      - 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
      Veja src/VREF/VOTES para a implementação.

    • e assim por diante…

    Apenas uma sidenote. Você também pode usar o Gerrit para suas necessidades:

    Revisão do código de Gerrit

    Primeiro parece que o Gerrit é usado para revisão de código, mas você pode usá-lo também para gerenciar usuários e dar-lhes boas permissions definidas. Você pode ignorar a revisão de código (através de controles de access ) e usá-lo apenas para gerenciar projetos e chaves ssh. O Gerrit tem um mecanismo de controle de access muito forte:

    Controles de Acesso Gerrit

    Você pode restringir o envio de quaisquer ramificações, tags ou qualquer coisa que possa imaginar que esteja definida no documento de controles de access.

    Para uma solução ainda mais rápida e suja, basta usar o daemon git e ir de peer-to-peer. Aqui está um artigo sobre como fazer isso.

    Edit: Eu reconheço isso não responde estritamente a pergunta do OP. Eu coloco isso aqui principalmente para aqueles que, como eu, se deparam com isso enquanto procuram uma maneira inadequada de compartilhar código até que uma conta do github corporativo seja configurada.

    Eu tenho andado por aí um tempinho para ter um servidor git trabalhando com access LDAP, controle de access refinado etc … Encontrei uma revelação: Use o Gitlab :

    • repositorys git
    • access fino granulado (afaik gitlab usa gitolite sob o capô)

    se você quiser o método de instalação rápido e rápido: use o instalador bitnami