29. Oktober 2021

| Timm Rose

Gitlab best practices

29. Oktober 2021

| Timm Rose

Gitlab best practices

1. Merge Request

Zu Gitlab best practices gehört das Erstellen eines Merge Requests

Möchtest du einen Merge Request (manchmal wird auch von Pull Request gesprochen) stellen, gibt es grundsätzlich mehrere Möglichkeiten. Eine Möglichkeit ist, direkt über die Gitlab Oberfläche den Merge Request manuell zu stellen.

Dafür wählst du in der linken Sidebar „Merge requests“ und kannst in der öffnenden Übersicht nun den Button „New merge request“ wählen.

Zur Eingabe wird nun der Source Branch benötigt. Das ist der Branch, der die Changes enthält und in den Target Branch gemergt werden soll.

Der Target Branch ist vorausgewählt, hier wird der Hauptbranch angezeigt. Je nach Konfiguration ist das der master oder main, oder ein ganz anderer frei gewählter Branchname.

Mit dem Button „Compare branches and continue“ wird der Merge Request vorbereitet. In der darauffolgenden Übersicht wird das Formular vervollständigt, indem der Titel, eine Beschreibung, der Bevollmächtigte (Assignee) und weitere Angaben eingetragen werden können.

Mit dem Button „Submit merge request“ wird der Merge Request erstellt und je nach konfigurierten Benachrichtigungen mindestens der Assignee per Mail informiert, einen ausstehenden Merge zu prüfen und gegebenenfalls mit Anmerkungen zurückzugeben oder zu mergen.

Merge blocked-Meldung

Möchtest du in der Gitlab Oberfläche einen Merge Request mergen, kann unter bestimmten Umständen die folgende Meldung auftreten:

!

Merge blocked: fast-forward merge is not possible. To merge this request, first rebase locally.

In diesem Fall warnt Gitlab vor zu erwartenden Konflikten, sodass ein merge beziehungsweise rebase nicht ausgeführt werden kann.

Der rebase muss lokal durchgeführt und Konflikte entsprechend manuell gelöst werden. Dazu gehst du wie folgt vor:

1. Den lokalen Haupt-Branch (z. B. main oder master) auschecken

$ git checkout main

2. Aktuelle Changes in den main Branch pullen

$ git pull origin main

3. Den Feature-Branch auschecken

$ git checkout <feature-branch>

4. rebase durchführen

$ git rebase origin/main

Der Rebase wird nun an der Stelle gestoppt, an der Git nicht toolgestützt mergen kann. Zu erkennen ist das an der Konsolenausgabe.

Zum Einen wird Branchname nicht mehr in dem üblichen Muster angezeigt

<user-name> ~/C:/Projects/ (<feature-branch>)

Der Branchname wird mit einem Rebase-Flag angezeigt und zusätzlich der Commit (REBASE 5/9), an dem der Rebase unterbrochen wurde

<user-name> ~/C:/Projects/ (<feature-branch>|REBASE 5/9)

An dieser Stelle wechselst du in deine IDE (Integrated Development Environment) und behebst die Merge Konflikte in den jeweiligen Dateien manuell.

Danach müssen diese Dateien dem Stage hinzugefügt werden

$ git add src/file01

Und danach der Commit abgesetzt werden, z. B. wie folgt

$ git commit -m "rebase 5/9: merge conflict fixed"

Die Konsolenausgabe gibt den Hinweis, dass der Rebase mit folgendem Befehle fortgesetzt werden kann

$ git rebase --continue

Die folgende Konsolenausgabe gibt eigentlich den Hinweis, jetzt ein $ git pull zu verwenden.

!

Your branch and ‚origin/‘ have diverged, and have 10 and 6 different commits each, respectively. (use „git pull“ to merge the remote branch into yours)

Ein Pull würde allerdings zu einem Kreislauf der „unresolved changes“ führen, in dessen Folge auf ein $ git push hingewiesen werden würde, der wiederum auf die gleichen zu lösenden Konflikte führt.

Daher muss statt dem Pull ein Push mit dem Flag –force die Changes erzwingen

$ git push --force 

Digitale Rundschau Logo

© 2021 Digitale Rundschau | Impressum