gitosis vs gitolite? [fechadas]

Estou procurando instalar um servidor git para compartilhar projetos com minha equipe. Não quero criar uma conta de usuário no servidor com acesso SSH para cada desenvolvedor que precise de um acesso git. Parece que existem duas soluções concorrentes que cobrem esse problema: gitosis e gitolite.

Não encontrei nenhuma comparação entre as duas soluções. Quais são as principais diferenças entre eles? Existe outra solução semelhante?

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

Você pode apenas usar git.

Para ter um servidor git, a única coisa que você precisa no servidor remoto é git. Se você não precisar de permissões refinadas (o compartilhamento apenas com sua equipe sugere que isso é uma possibilidade) ou qualquer recurso extra, não precisará de gitolite ou similar.

A solução sem instalação

Se o git estiver disponível no servidor remoto, você poderá fazer o que está pedindo 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ê deseja fazer as coisas com um usuário git dedicado, os documentos para configurar um servidor git são curtos - porque é realmente muito fácil de fazer.

Em suma:

• Instale o git
• Crie um usuário chamado git
• Adicione suas chaves públicas e de sua equipe ao .ssh/authorized_keysarquivo do usuário git
• Mude o shell do usuário git para ser git-shell
• Criar repositórios no servidor
• inicie o git pull / empurrando para [email protected]

A única diferença entre o uso de um usuário git dedicado e não é que, se você configurar o usuário git, git-shellele não se permitirá fazer mais nada. Porém, em termos de atuar como um servidor git, é idêntico à solução sem instalação

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

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

Seu recurso mais interessante é o Virtual Reference (VREF, abreviado), que permite declarar quantos ganchos de atualização você deseja, o que permite restringir um envio pressionando:

• dir / nome do arquivo :
  digamos que você não queira que os desenvolvedores juniores façam alterações no Makefile, porque é bastante complexo:
  - VREF/NAME/Makefile = @junior-devs

• número de novos arquivos :
  digamos que você não queira que os desenvolvedores juniores enviem mais de 9 arquivos por confirmação, porque deseja que eles façam pequenas confirmações:
  - VREF/COUNT/9/NEWFILES = @junior-devs

• detecção avançada de tipo de arquivo :
  Às vezes, um arquivo possui uma extensão padrão (que não pode ser 'ignorada'), mas na verdade é gerado automaticamente. Aqui está uma maneira de capturá-lo:
  - VREF/FILETYPE/AUTOGENERATED = @all
  Veja src/VREF/FILETETYPEpara ver o mecanismo de detecção.

• verificando o e - mail do autor :
  algumas pessoas querem garantir que "você só pode enviar seus próprios commit".
  - VREF/EMAIL-CHECK = @all
  Veja src/VREF/EMAIL-CHECK.

• votação sobre commits :
  A implementação básica de votar 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/VOTESpara a implementação.

• e assim por diante...

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

Revisão do Código Gerrit

Primeiro, parece que o Gerrit é usado para a revisão de código, mas você também pode usá-lo também para gerenciar usuários e conceder boas permissões definidas. Você pode ignorar a revisão de código (através dos controles de acesso ) e usá-lo apenas para gerenciar projetos e chaves ssh. A Gerrit possui um mecanismo de controle de acesso realmente forte:

Controles de acesso Gerrit

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

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

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

Eu tenho mexido por um tempo para obter um servidor git trabalhando com acesso LDAP, controle de acesso refinado, etc ... Encontrei uma revelação: Use o Gitlab :

• repositórios git
• acesso granular (o afaik gitlab usa gitolite sob o capô)

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