gitosis vs gitolita? [cerrado]

Estoy buscando instalar un servidor git para compartir proyectos con mi equipo. No quiero crear una cuenta de usuario en el servidor con acceso SSH para cada desarrollador que necesite un acceso git. Parece que hay dos soluciones concurrentes que cubren este problema: gitosis y gitolita.

No pude encontrar ninguna comparación entre ambas soluciones. ¿Cuáles son las principales diferencias entre ellos? ¿Hay otra solución similar?

Estoy buscando instalar un servidor git para compartir proyectos con mi equipo.

Puede simplemente usar Git.

Para tener un servidor git, lo único que necesita en el servidor remoto es git. Si no necesita permisos detallados (compartir solo con su equipo sugiere que es una posibilidad) o cualquier característica adicional, no necesita gitolita o similar.

La solución sin instalación

Si git está disponible en el servidor remoto, puede hacer lo que está pidiendo en este momento, sin hacer nada

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

En la zona:

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

Configurar un servidor git es fácil.

Si desea hacer cosas con un usuario de git dedicado, los documentos para configurar un servidor de git son cortos, porque realmente es bastante fácil de hacer.

En resumen:

• Instalar git
• Crea un usuario llamado git
• Agregue sus claves públicas y las de su equipo al .ssh/authorized_keysarchivo del usuario de git
• Cambia el shell del usuario git para que sea git-shell
• Crear repositorios en el servidor
• iniciar git pull / empujar a [email protected]

La única diferencia entre usar un usuario de git dedicado y no, es que si configura el usuario de git para que lo use git-shell, no se permitirá hacer nada más. Sin embargo, en términos de actuar como un servidor git, es idéntico a la solución sin instalación

La principal diferencia es que la gitosis ahora es obsoleta y ya no se mantiene activamente.

Gitolite tiene muchas más funciones completas y acaba de lanzar su tercera versión .

Su característica más interesante es la Referencia virtual (VREF para abreviar) que le permite declarar todos los enlaces de actualización que desee, lo que le permite restringir un impulso mediante:

• dir / nombre de archivo :
  Digamos que no desea que los desarrolladores junior empujen los cambios al Makefile, porque es bastante complejo:
  - VREF/NAME/Makefile = @junior-devs

• cantidad de archivos nuevos :
  supongamos que no desea que los desarrolladores junior envíen más de 9 archivos por confirmación, porque desea que hagan pequeñas confirmaciones:
  - VREF/COUNT/9/NEWFILES = @junior-devs

• detección avanzada de tipo de archivo : a
  veces un archivo tiene una extensión estándar (que no se puede 'gitignore'd), pero en realidad se genera automáticamente. Aquí hay una forma de atraparlo:
  - VREF/FILETYPE/AUTOGENERATED = @all
  vea src/VREF/FILETETYPEpara ver el mecanismo de detección.

• revisar el correo electrónico del autor :
  Algunas personas quieren asegurarse de que "solo puede impulsar sus propios compromisos".
  - VREF/EMAIL-CHECK = @all
  Ver src/VREF/EMAIL-CHECK.

• votación de confirmaciones :
  Una implementación básica de votación sobre un commit es sorprendentemente 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
  Ver src/VREF/VOTESpara la implementación.

• y así...

Solo una nota al margen. También puede usar Gerrit para sus necesidades:

Revisión del Código Gerrit

Primero, parece que Gerrit se usa para la revisión del Código, pero en realidad puede usarlo también para administrar usuarios y otorgarles buenos permisos definidos. Puede omitir la revisión de código ( controles de acceso a través ) y usarla solo para administrar proyectos y teclas ssh. Gerrit tiene un mecanismo de control de acceso realmente fuerte:

Controles de acceso de Gerrit

Puede restringir la inserción de cualquier rama, etiqueta o cualquier cosa que pueda imaginar que esté definida en el documento de controles de acceso.

Para una solución aún más rápida y sucia, solo usa git daemon y ve de igual a igual. Aquí hay un artículo sobre hacer exactamente eso.

Editar: reconozco que esto no responde estrictamente a la pregunta del OP. Puse esto aquí principalmente para aquellos, como yo, que se encuentran con esto mientras buscan una forma sucia de compartir código hasta que se configure una cuenta empresarial de github.

He estado jugando durante un tiempo para que un servidor git funcione con acceso LDAP, control de acceso de grano fino, etc. Encontramos una revelación: use Gitlab :

• repositorios git
• acceso de grano fino (afaik gitlab usa gitolita debajo del capó)

si desea el método de instalación rápido y rápido: use el instalador de bitnami