GitLab server

Een GIT-repository willen we beschikbaar stellen voor ander programmeurs zodat we als team aan wijzigingen/bugs/updates kunnen werken. Hiervoor dient de repository op een git-server geplaatst te worden. Deze server kan in de cloud staan of ‘on-premise‘. Cloud GIT-server zijn populair en beschikbaar in diverse ‘smaken’. De populairste zijn

  • GitHub – https://github.com
  • GitLab – https://gitlab.com
  • BitBucket – https://bitbucket.org
  • SourgeForce – https://sourceforce.net

GitLab server ‘on-premise’

Mocht het, om wat voor reden dan ook, gewenst zijn om de git-server in eigen beheer en ‘on-premise’ te draaien, dan is GitLab de meest geschikte open-source kandidaat. GitLab kan op de meest populaire Linux varianten geïnstalleerd worden, zelfs op een Raspberry Pi is dit mogelijk of als containers in een Kubernetes cluster. Voor instructies, kijk op: https://about.gitlab.com/install/

Eenmaal geinstalleerd wordt een browser gebruikt naar de geregistreerde URL van GitLab, bijvoorbeeld https://gitlab.yourdomain.com

De eerste keer na inloggen wordt bovenstaand scherm getoond. Het is handig om projecten in groepen te plaatsen en daarom wordt eerst een groep gemaakt. DUs… ‘Create a group

Nadat de groep in aangemaakt, kunnen Projecten worden toegevoegd. ‘New Project

Na het aanmaken van het Project worden de instructies weergegeven om je bestanden in de repository te plaatsen. We gaan onze code van de lokale git repository die we eerder hebben aangemaakt, in dit project op de GitLab server zetten. De instructies:

$ cd project-directory 
$ git init 
$ git remote add origin https://gitlab.yourdomain.com/mijn-voorbeeld-groep/mijn-voorbeeld-project.git 
$ git add . 
$ git commit -m "Initial commit" 
$ git push -u origin master

Gebruik de ‘username’ en ‘password’ voor de GitLab server.

origin‘ is de locatie van de repository op de GitLab server. Deze is met ‘git remote‘ toegevoegd aan de config-file van git in het project. Met ‘git push‘ wordt de lokale master repository naar de origin locatie gestuurd.

Ververs het scherm van de browser en er verschijnt een menu-optie ‘Repository’ bij en de bestanden uit het project worden nu op het scherm getoond.

Het project kan nu door ‘Members‘ van dir poject opgehaald worden. Via het menu aan de linkerkant kunnen Members uitgenodigd worden. Het ophalen van de repository gaat met het ‘git clone‘ commando en daarvoor is de ‘Clone’ button in de getoonde repository.

Aangezien wij de repository lokaal al hebben is het niet nodig om de repository te clonen. Wijzigingen van anderen die gemerged zijn naar master, kunnen wij ophalen met ‘git pull’

$ git pull origin master

Hierna kunnen we zelf een branch maken, wijzigingen aanbrengen en de branch pushen naar de git-server:

$ git branch wijzigingen-02
$ git checkout wijzigingen-02
... wijzig nu bijvoorbeeld het README.md bestand ...
$ git add README.md
$ git commit -m "Wijziging in README bestand"
$ git push --set-upstream origin wijzigingen-02

Dat laatste commando dient ervoor om de lokale branch toe te voegen aan de GitLab-server, die heeft deze branch immers nog niet. Er verschijnt dan ook de volgende tekst:

To https://gitlab.yourdomain.com/mijn-voorbeeld-groep/mijn-voorbeeld-project.git
* [new branch]      wijzigingen-02 -> wijzigingen-02
Branch 'wijzigingen-02' set up to track remote branch 'wijzigingen-02' from 'origin'. 

Via de menu-optie ‘Repository -> Branches‘ op de GitLab server, zie je nu de twee branches ‘master’ en ‘wijzigingen-02’

Tevens wordt er nu een button genaamd ‘Merge request‘ getoond en die gaan we nu gebruiken om de ‘wijzigingen-02’ te mergen met de ‘master’ branch. Echter, we doen een merge-aanvraag aan één of meer van onze Project-members en die gaan (hopelijk) toestemming geven om de branches te mergen.

Met een ‘Submit merge request’ wordt de aanvraag verstuurd. Nadat een member de aanvraag heeft goedgekeurd kan de wiziging ge-merged worden. Je vindt de ‘Merge Requests‘ terug via het menu aan de linkerkant.

Merge en verwijder de source branch (wijzigingen-02) We pakken gelijk de nieuwe master branch op door deze naar onze lokale computer te pullen en verwijderen de tijdelijke branch.

$ git checkout master 
$ git pull origin master
$ git branch wijzigingen-02 -D

Terug naar oude(re) versie

Nu blijkt de laatste ge-mergde versie niet goed te zijn en moeten we terug naar één van de vorige versies. Hier blijkt de omschrijving van de commit-commando’s een handig hulpmiddel en met ‘git log’ zien we de commits.

commit 87784db9492a39e4e9c99269591d4d5a923c2c91 (origin/wijzigingen-02)
Author: Nico Oosterwijk nico@digitalinfo.nl
Date:   Fri Sep 18 15:26:33 2020 +0200

   Wijziging in README bestand

commit fd749466369d4d717e12626b2b8428a6be1db2a7
Author: Nico Oosterwijk nico@digitalinfo.nl
Date:   Fri Sep 18 15:11:45 2020 +0200

   Initial commit

We gaan in dit geval terug naar de ‘Initial commit’ en die heeft commit id ‘fd749466369d4d717e12626b2b8428a6be1db2a7’, we geven het volgende commando:

$ git revert fd749466369d4d717e12626b2b8428a6be1db2a7

Dit geeft nu een zogenaamde ‘Merge Conflict‘ en dat is te zien in het bestand README.md.

# Voorbeeld Project
<<<<<<< HEAD
## Dit project bevat de bestanden uit het voorbeeld van mijn blog.

In dit geval alleen een README.md bestand.
=======
## Dit project bevat de bestanden uit het voorbeeld van mijn blog artikel.
                                                             
>>>>>>> parent of fd74946… Initial commit                                                 

Alles tussen ‘<<<<<< HEAD‘ en ‘======‘ is de originele master branch en tussen ‘======‘ en ‘>>>>>>>‘ is hetgeen we terug willen uit de initiele commit.

De onjuiste master branch gaan we vervangen door de ‘initial commit’ dus het eerste deel gaat weg. Nu blijft alleen de volgende tekst over:

## Voorbeeld Project

# Dit project bevat de bestanden uit het voorbeeld van mijn blog artikel.

Dit gaan we nu weer terugplaatsen met:

$ git add README.md
$ git commit -m "Revert Initial commit"
$ git push

et voila, de initial commit is terug in de master repository.

Happy coding…!