Estoy intentando instalar un servidor Git en una caja RedHat 6.5.
Estoy siguiendo estos tutoriales:1,2,3, y para ser honesto, cuanto más leo, más se vuelven oscuras las cosas.
Si debo crear un usuario de git que será el propietario de los repositorios principales y también estará a cargo de realizar las confirmaciones, ¿cómo evito que un desarrollador envíe un código incorrecto (gitolite, ¿hay algo más nuevo?)?
¿Cuál es la configuración más simple para el servidor git (me encantaría gitlab pero mi jefe no lo permite) y al mismo tiempo permitir que el desarrollador envíe solo cuando el código ha sido revisado y se le ha otorgado permiso para realizar el envío?
nota: todos los desarrolladores tienen acceso ssh al servidor. y he recopilado sus claves ssh.pub
Respuesta1
Para responder tu pregunta:
Si debo crear un usuario de git que será el propietario de los repositorios principales y también estará a cargo de realizar las confirmaciones, ¿cómo evito que un desarrollador envíe un código incorrecto?
La respuesta no es crear un usuario de git. Puede controlar los permisos de acceso al repositorio remoto con usuarios y grupos estándar de UNIX. Dado que git impulsa el trabajo a través de SSH, siempre que pueda utilizar SSH en el servidor que aloja el repositorio y tenga acceso de lectura al repositorio a través de su cuenta en el servidor, podrá leer, clonar y extraer archivos de los repositorios. Si también tiene permisos de escritura en el repositorio, también puede enviar confirmaciones.
Respuesta2
Una de las cosas habilitadas de forma predeterminada en git es:
git push --force
En los casos normales, siempre debes desactivar esto en el repositorio mediante:
git config --system receive.denyNonFastForwards true
El problema puede surgir con el escenario de flujo de trabajo de fusión cuando puede tener muchas solicitudes de extracción, pero siempre la mejor solución es tener buenas tareas de desarrollo separadas y de fusión donde los desarrolladores realmente puedan entender git y no comprometerse tanto (principalmente porque no entienden la naturaleza). de control de versiones) y si eso está bien, tendrás menos conflictos. Una buena formación y comprensión siempre es lo mejor. También puede evitar esto con las confirmaciones de rebase localmente. La segunda alternativa es quizás Github. En ese escenario, no permite que más de un mantenedor acceda a las ramas importantes en el repositorio autorizado.