GitWeb és bastant simplista. Si esteu buscant un servidor Git modern i completament equipat, hi ha diverses solucions de codi obert que podeu instal·lar en el seu lloc. Com que GitLab és una de les més populars, tractarem la seva instal·lació i ús com a exemple. Això és més difícil que l’opció GitWeb i requerirà més manteniment, però és una opció completa.
GitLab és una aplicació web amb suport de base de dades, per la qual cosa la seva instal·lació és més complexa que la d’alguns altres servidors Git. Afortunadament, aquest procés està ben documentat i suportat. GitLab recomana fortament instal·lar GitLab al vostre servidor mitjançant el paquet oficial Omnibus GitLab.
Les altres opcions d’instal·lació són:
-
Gràfic Helm de GitLab, per a ús amb Kubernetes.
-
Paquets Docker de GitLab per a ús amb Docker.
-
Des dels fitxers font.
-
Proveïdors de núvol com AWS, Google Cloud Platform, Azure, OpenShift i Digital Ocean.
Per a més informació, llegiu el README de GitLab Community Edition (CE).
La interfície d’administració de GitLab s’accedeix a través de la web.
Simplement apunteu el vostre navegador al nom d’amfitrió o adreça IP on GitLab està instal·lat, i inicieu sessió com a usuari root.
La contrasenya dependrà del tipus d’instal·lació, però per defecte, Omnibus GitLab genera automàticament una contrasenya i l’emmagatzema a /etc/gitlab/initial_root_password durant almenys 24 hores.
Seguiu la documentació per a més detalls.
Un cop hàgiu iniciat sessió, feu clic a la icona “Àrea d’administració” al menú a la part superior dreta.
Tothom que utilitzi el vostre servidor GitLab ha de tenir un compte d’usuari.
Els comptes d’usuari són bastant senzills, principalment contenen informació personal adjunta a les dades d’inici de sessió.
Cada compte d’usuari té un namespace, que és una agrupació lògica de projectes que pertanyen a aquest usuari.
Si l’usuari jane tingués un projecte anomenat project, l’URL d’aquest projecte seria http://server/jane/project.
Podeu eliminar un compte d’usuari de dues maneres: “Bloquejar” un usuari li impedeix iniciar sessió a la instància de GitLab, però totes les dades sota el namespace d’aquest usuari es preservaran, i els commits signats amb l’adreça de correu electrònic d’aquest usuari encara enllaçaran al seu perfil.
“Destruir” un usuari, d’altra banda, l’elimina completament de la base de dades i del sistema de fitxers. Tots els projectes i dades al seu namespace són eliminats, i qualsevol grup que posseïti també serà eliminat. Això és clarament una acció molt més permanent i destructiva, i rarament la necessitareu.
Un grup de GitLab és una col·lecció de projectes, juntament amb dades sobre com els usuaris poden accedir a aquests projectes.
Cada grup té un namespace de projecte (de la mateixa manera que els usuaris), així que si el grup training té un projecte materials, la seva URL seria http://server/training/materials.
Cada grup està associat amb diversos usuaris, cadascun dels quals té un nivell de permisos per als projectes del grup i el grup en si. Aquests van des de “Convidat” (només problemes i xat) fins a “Propietari” (control complet del grup, els seus membres i els seus projectes). Els tipus de permisos són massa nombrosos per llistar-los aquí, però GitLab té un enllaç útil a la pantalla d’administració.
Un projecte de GitLab correspon aproximadament a un únic repositori Git. Cada projecte pertany a un únic namespace, ja sigui un usuari o un grup. Si el projecte pertany a un usuari, el propietari del projecte té control directe sobre qui té accés al projecte; si el projecte pertany a un grup, els permisos a nivell d’usuari del grup entraran en vigor.
Cada projecte té un nivell de visibilitat, que controla qui té accés de lectura a les pàgines i al repositori d’aquest projecte.
Si un projecte és Privat, el propietari del projecte ha de concedir accés explícitament a usuaris específics.
Un projecte Intern és visible per a qualsevol usuari que hagi iniciat sessió, i un projecte Públic és visible per a qualsevol persona.
Noteu que això controla tant l’accés git fetch com l’accés a la interfície web per a aquest projecte.
GitLab inclou suport per a ganchos, tant a nivell de projecte com de sistema. Per a qualsevol d’aquests, el servidor GitLab realitzarà una petició HTTP POST amb algun JSON descriptiu sempre que es produeixin esdeveniments rellevants. Aquesta és una bona manera de connectar els vostres repositoris Git i la instància de GitLab amb la resta de la vostra automatització de desenvolupament, com servidors de CI, sales de xat o eines de desplegament.
El primer que voldreu fer amb GitLab és crear un nou projecte. Podeu fer això fent clic a la icona “+” a la barra d’eines. Se us demanarà el nom del projecte, a quin namespace ha de pertànyer i quin ha de ser el seu nivell de visibilitat. La majoria del que especifiqueu aquí no és permanent i es pot canviar més tard a través de la interfície de configuració. Feu clic a “Crea el Projecte”, i ja esteu fets.
Un cop el projecte existeix, probablement voldreu connectar-lo amb un repositori Git local.
Cada projecte és accessible a través d’HTTPS o SSH, qualsevol dels quals es pot utilitzar per configurar un Git remote.
Les URLs són visibles a la part superior de la pàgina d’inici del projecte.
Per a un repositori local existent, aquesta ordre crearà un remote anomenat gitlab a la ubicació allotjada:
$ git remote add gitlab https://server/namespace/project.gitSi no teniu una còpia local del repositori, simplement podeu fer això:
$ git clone https://server/namespace/project.gitLa interfície web proporciona accés a diverses vistes útils del repositori en si. La pàgina d’inici de cada projecte mostra l’activitat recent i els enllaços a la part superior us portaran a vistes dels fitxers del projecte i el registre de commits.
La manera més senzilla de treballar junts en un projecte de GitLab és donant a cada usuari accés directe de push al repositori Git. Podeu afegir un usuari a un projecte anant a la secció “Membres” de la configuració d’aquest projecte i associant el nou usuari amb un nivell d’accés (els diferents nivells d’accés es discuteixen una mica a Grups). En donar a un usuari un nivell d’accés de “Desenvolupador” o superior, aquest usuari pot enviar commits i branques directament al repositori.
Una altra manera, més desacoblada, de col·laborar és mitjançant sol·licituds de fusió.
Aquesta característica permet a qualsevol usuari que pugui veure un projecte contribuir-hi de manera controlada.
Els usuaris amb accés directe poden simplement crear una branca, enviar commits a ella i obrir una sol·licitud de fusió des de la seva branca cap a master o qualsevol altra branca.
Els usuaris que no tenen permisos de push per a un repositori poden “bifurcar” per crear la seva pròpia còpia, enviar commits a la seva còpia i obrir una sol·licitud de fusió des de la seva bifurcació cap al projecte principal.
Aquest model permet al propietari estar en ple control del que entra al repositori i quan, mentre permet contribucions d’usuaris no confiables.
Les sol·licituds de fusió i els problemes són les unitats principals de discussió de llarga durada a GitLab. Cada sol·licitud de fusió permet una discussió línia per línia del canvi proposat (que admet una mena lleugera de revisió de codi), així com un fil de discussió general. Tots dos poden ser assignats a usuaris o organitzats en fites.
Aquesta secció està centrada principalment en les característiques relacionades amb Git de GitLab, però com a projecte madur, proporciona moltes altres característiques per ajudar el vostre equip a treballar junts, com ara wikis de projecte i eines de manteniment del sistema. Un benefici de GitLab és que, un cop el servidor està configurat i en funcionament, rarament necessitareu ajustar un fitxer de configuració o accedir al servidor mitjançant SSH; la majoria de l’administració i l’ús general es poden fer a través de la interfície del navegador.