-
1. Inicio - Sobre el Control de Versiones
-
2. Fundamentos de Git
-
3. Ramificaciones en Git
-
4. Git en el Servidor
- 4.1 Los Protocolos
- 4.2 Configurando Git en un servidor
- 4.3 Generando tu clave pública SSH
- 4.4 Configurando el servidor
- 4.5 El demonio Git
- 4.6 HTTP Inteligente
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git en un alojamiento externo
- 4.10 Resumen
-
5. Git en entornos distribuidos
-
6. GitHub
-
7. Herramientas de Git
- 7.1 Revisión por selección
- 7.2 Organización interactiva
- 7.3 Guardado rápido y Limpieza
- 7.4 Firmando tu trabajo
- 7.5 Buscando
- 7.6 Reescribiendo la Historia
- 7.7 Reiniciar Desmitificado
- 7.8 Fusión Avanzada
- 7.9 Rerere
- 7.10 Haciendo debug con Git
- 7.11 Submódulos
- 7.12 Agrupaciones
- 7.13 Replace
- 7.14 Almacenamiento de credenciales
- 7.15 Resumen
-
8. Personalización de Git
-
9. Git y Otros Sistemas
- 9.1 Git como Cliente
- 9.2 Migración a Git
- 9.3 Resumen
-
10. Los entresijos internos de Git
-
A1. Apéndice A: Git en otros entornos
- A1.1 Interfaces gráficas
- A1.2 Git en Visual Studio
- A1.3 Git en Eclipse
- A1.4 Git con Bash
- A1.5 Git en Zsh
- A1.6 Git en Powershell
- A1.7 Resumen
-
A2. Apéndice B: Integrando Git en tus Aplicaciones
- A2.1 Git mediante Línea de Comandos
- A2.2 Libgit2
- A2.3 JGit
-
A3. Apéndice C: Comandos de Git
- A3.1 Configuración
- A3.2 Obtener y Crear Proyectos
- A3.3 Seguimiento Básico
- A3.4 Ramificar y Fusionar
- A3.5 Compartir y Actualizar Proyectos
- A3.6 Inspección y Comparación
- A3.7 Depuración
- A3.8 Parcheo
- A3.9 Correo Electrónico
- A3.10 Sistemas Externos
- A3.11 Administración
- A3.12 Comandos de Fontanería
4.8 Git en el Servidor - GitLab
GitLab
GitWeb es muy simple. Si buscas un servidor Git más moderno, con todas las funciones, tienes algunas soluciones de código abierto que puedes utilizar en su lugar. Puesto que GitLab es una de las más populares, vamos a ver aquí cómo se instala y se usa, a modo de ejemplo. Es algo más complejo que GitWeb y requiere algo más de mantenimiento, pero es una opción con muchas más funciones.
Instalación
GitLab es una aplicación web con base de datos, por lo que su instalación es algo más complicada. Por suerte, es un proceso muy bien documentado y soportado.
Hay algunos métodos que puedes seguir para instalar GitLab. Para tener algo rápidamente, puedes descargar una máquina virtual o un instalador one-click desde https://bitnami.com/stack/gitlab, y modificar la configuración para tu caso particular. La pantalla de inicio de Bitnami (a la que se accede con alt-→); te dirá la dirección IP y el usuario y contraseña utilizados para instalar GitLab.
Para las demás cosas, utiliza como guía los archivos readme de la edición Community de GitLab, que se pueden encontrar en https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Aquí encontrarás ayuda para instalar Gitlab usando recetas Chef, una máquina virtual para Digital Ocean, y paquetes RPM y DEB (los cuales, en el momento de escribir esto, aun estaban en beta). También hay guías “no oficiales” para configurar GitLab en sistemas operativos o con bases de datos no estándar, un script de instalación completamente manual y otros muchos temas.
Administración
La interfaz de administración de GitLab se accede mediante la web.
Simplemente abre en tu navegador la IP o el nombre de máquina donde has instalado
Gitlab, y entra con el usuario administrador. El usuario predeterminado es
admin@local.host
, con la contraseña 5iveL!fe
(que te pedirá cambiar cuando
entres por primera vez).
Una vez dentro, pulsa en el icono “Admin area” del menú superior derecho.
Usuarios
Los usuarios en Gitlab son las cuentas que abre la gente.
Las cuentas de usuario no tienen ninguna complicación: viene a ser una colección
de información personal unida a la información de login.
Cada cuenta tiene un espacio de nombres (namespace) que es una agrupación
lógica de los proyectos que pertenecen al usuario.
De este modo, si el usuario jane
tiene un proyecto llamado project
, la
URL de ese proyecto sería http://server/jane/project.
Tenemos dos formas de borrar usuarios. “Bloquear” un usuario evita que el usuario entre en Gitlab, pero los datos de su espacio de nombres se conservan, y los commits realizados por el usuario seguirán a su nombre y relacionados con su perfil.
“Destruir” un usuario, por su parte, borra completamente al usuario de la base de datos y el sistema de archivos. Todos los proyectos y datos de su espacio de nombres se perderán, así como cualquier grupo que le pertenezca. Esto es, por supuesto, la acción más permanente, destructiva y casi nunca se usa.
Grupos
Un grupo de GitLab es un conjunto de proyectos, junto con los datos acerca
de los usuarios que tienen acceso. Cada grupo tiene también un espacio de nombres
específico (al igual que los usuarios). Por ejemplo, si el grupo formacion
tuviese un proyecto materiales
su URL sería:
http://server/formacion/materiales.
Cada grupo se asocia con un conjunto de usuarios, donde cada usuario tiene un nivel de permisos sobre los proyectos así como el propio grupo. Estos permisos van desde el de “Invitado” (que solo permite manejar incidencias y chat) hasta el de “Propietario” (con control absoluto del grupo, sus miembros y sus proyectos). Los tipos de permisos son muy numerosos para detallarlos aquí, pero en la ayuda de la pantalla de administración de GitLab los encontraremos fácilmente.
Proyectos
Un proyecto en GitLab corresponde con un repositorio Git. Cada proyecto pertenece a un espacio de nombres, bien sea de usuario o de grupo. Si el proyecto pertenece a un usuario, el propietario del mismo tendrá control directo sobre quién tiene acceso al proyecto; si el proyecto pertenece a un grupo, los permisos de acceso por parte de los usuarios estarán también determinados por los niveles de acceso de los miembros del grupo.
Cada proyecto tiene también un nivel de visibilidad, que controla quién tiene acceso de lectura a las páginas del proyecto y al propio repositorio. Si un proyecto es Privado, el propietario debe conceder los accesos para que determinados usuarios tengan permisos. Un proyecto Interno es visible a cualquier usuario identificado, y un proyecto Público es visible a todos, incluso usuarios no identificados y visitantes. Observa que esto controla también el acceso de lectura git (“fetch”) así como el acceso a la página web del proyecto.
Enganches (hooks)
GitLab tiene soporte para los enganches (hooks), tanto a nivel de proyecto como del sistema. Para cualquiera de ellos, el servidor GitLab realizará una petición HTTP POST con determinados datos JSON cuando ocurran ciertos eventos. Es una manera interesante de conectar los repositorios y la instancia de GitLab con el resto de los mecanismos automáticos de desarrollo, como servidores de integración continua (CI), salas de charla y otras utilidades de despliegue.
Uso básico
Lo primero que tienes que hacer en GitLab es crear un nuevo proyecto. Esto lo consigues pulsando el icono “+” en la barra superior. Te preguntará por el nombre del proyecto, el espacio de nombres al que pertenece y qué nivel de visibilidad debe tener. Esta información, en su mayoría, no es fija y puedes cambiarla más tarde en la pantalla de ajustes. Pulsa en “Create Project” y habrás terminado.
Una vez que tengas el proyecto, querrás usarlo para un repositorio local de
Git. Cada proyecto se puede acceder por HTTPS o SSH, protocolos que podemos
configurar en nuestro repositorio como un Git remoto. La URL la encontrarás
al principio de la página principal del proyecto. Para un repositorio
local existente, puedes crear un remoto llamado gitlab
del siguiente modo:
$ git remote add gitlab https://server/namespace/project.git
Si no tienes copia local del repositorio, puedes hacer esto:
$ git clone https://server/namespace/project.git
La interfaz web te permite acceder a diferentes vistas interesantes del repositorio. Además, la página principal del proyecto muestra la actividad reciente, así como enlaces que permiten acceder a los archivos del proyecto y a los diferentes commits.
Trabajando con GitLab
Para trabajar en un proyecto GitLab lo más simple es tener acceso de escritura (push) sobre el repositorio git. Puedes añadir usuarios al proyecto en la sección “Members” de los ajustes del mismo, y asociar el usuario con un nivel de acceso (los niveles los hemos visto en Grupos). Cualquier nivel de acceso tipo “Developer” o superior, permite al usuario enviar commits y ramas sin ninguna limitación.
Otra forma de colaboración, más desacoplada, es mediante las peticiones
de fusión (merge requests). Esta característica permite a cualquier usuario
con acceso de lectura, participar de manera controlada. Los usuarios con
acceso directo pueden, simplemente, crear la rama, enviar commits y
luego abrir una petición de fusión desde su rama hacia la rama master
u otra cualquiera. Los usuarios sin permiso de push pueden hacer un
“fork” (es decir, su propia copia del repositorio), enviar sus cambios
a esa copia, y abrir una petición de fusión desde su fork hacia el proyecto
del que partió.
Este modelo permite al propietario tener un control total de lo que entra
en el repositorio, permitiendo a su vez la cooperación de usuarios
a los que no se confía el acceso total.
Las peticiones de fusión y las incidencias (issues) son las principales fuentes de discusión en los proyectos de GitLab. Cada petición de fusión permite una discusión sobre el cambio propuesto (similar a una revisión de código), así como un hilo de discusión general. Ambas pueden asignarse a usuarios, o ser organizadas en hitos (milestones).
Esta sección se ha enfocado principalmente hacia las características de GitLab relacionadas con Git, pero como proyecto ya maduro, tiene muchas otras características para ayudar en la coordinación de grupos de trabajo, como wikis de proyecto y utilidades de mantenimiento. Una ventaja de GitLab es que, una vez que el servidor está configurado y funcionando, rara vez tendrás que tocar un archivo de configuración o acceder al servidor mediante SSH; casi toda la administración y uso se realizará mediante el navegador web.