git/gitlab Cheatsheet

(Work in Progress)

Die wichtigsten Kommandos und Prozesse im Umgang mit den git-Repositories auf gitlab.hs-bremerhaven.de.

Dies ist keine ausreichende Einführung in git, sondern eine Handreichung um schnell einen ersten Zugriff auf die Dateien in den Repositories auf dem Gitlab-Server zu erhalten.

Vorbereitung

gitlab

Zugriff auf Gitlab muss eingerichtet sein. Für SSH-Zugriff auf die git-Repositories ist es notwendig einen SSH-Key in den Einstellungen des gitlab-Accounts einzurichten.

Die Gitlab-Repositories erreichen Sie entweder über HTTP oder SSH (Port 2022) über einen Proxy-Jump über hopper. Informationen dazu finden Sie im hopper-Tutorial von Oliver Radfelder.

Lokal

Auf ihrem eigenen Rechner müssen Sie jeweils noch die Konfiguration so einrichten, dass Ihre Commit-Nachrichten mit einem sinnvollen Namen “unterschrieben” werden. Sie tun das wie folgt durch Angabe eines Namens und einer Emailadresse.

git config [--local] user.email YOURACCOUNT@hs-bremerhaven.de
git config [--local] user.name  YOURACCOUNT

Das Setzen des Flags “local” sorgt dafür, dass diese Konfiguration nur im lokalen Repository gültig ist. Sie können also in unterschiedlichen Projekten mit unterschiedlichen Identitäten auftauchen.

Umgang mit Repositories

In jedem gitlab-Projekt finden sich Links auf das git-Repository des Projektes. (Pulldown Menu “Clone” in den Projektdetails.)

Lokale Kopie des Repositories erstellen:

git clone <git-repo-link>

Anzeige und Auswahl von Branches:

git branch -a
git checkout <branchname>

Aktualisieren des aktuellen, lokalen Branches:

git pull

Jetzt machen Sie Änderungen. Einfügen und einchecken der Änderungen in das lokale Repository:

git add <changed-files>
git commit 

Hochladen der Änderungen in das Quell-Repository:

git push

Entwickeln auf unsicheren Hosts

Beim experimentieren mit Infrastruktur ist es oft einfacher direkt auf dem entsprechenden Host zu testen. Gleichzeitig möchte ich meine privaten Schlüssel zum Repository nicht auf dem (potentiell unsicheren) Host lagern. Die Situation ist also, dass Code parallel auf dem Zielsystem (Host) und in einer separaten Entwicklungsumgebung (Laptop) weitergeschrieben wird.

Voraussetzung für diese Lösung ist, dass ich einen vertrauenswürdigen Rechner von dem aus ich mich mit dem Host (per SSH) verbinden kann und auf dem sich ein Clon des Repos befindet. Dann kann ich den Clon des Repos auf dem Host als remote auf dem Entwicklungsrechner eintragen.

Im Repository auf dem Entwicklingsrechner:

git remote add <name> <host>:<pfad auf host>
# z.B.:
git remote add tron tron:scenarios/wp48-damn-vulnerable-linux

Situation A) Änderungen auf dem Host

Auf dem Host normal die Änderungen committen:

git add <pfade>
git commit

um sich dann den neuesten Stand auf den Entwicklungsrechner holen und ggF. an ein zentrales Repository (origin) weiterreichen:

git pull <hostrepo>
git pull origin
# Merge-Probleme lösen
git push origin

und nicht vergessen etwaige Änderungen beim Zusammenführen mit dem zentralen Repository wieder auf den Host zurückzuspiegeln, wie im nächsten Abschnitt beschrieben.

Situation B) Änderungen auf dem Entwicklungsrechner

Du hast auf dem Entwicklungsrechner gearbeitet und möchtest es jetzt auf dem Host ausführen? Dann müssen deine Änderungen auf das Repository auf dem Host kommen. Dabei musst du ein wenig aufpassen, weil du nicht direkt in ein normales (nicht bare) Repository pushen kannst, oder normalerweise solltest.

Der Weg dorthin wird als push-to-deploy bezeichnet¹. Dafür musst du das Host-Repository passend konfigurieren.

git config receive.denyCurrentBranch updateInstead

Beim push in das Repo sollten sich dort keine lokalen Änderungen finden. (Eingeführt in git v2.3)

Zwei andere Varianten sind die Synchronisierung über ein zentrales Repository, oder ein zweites bare-Repository auf dem Host.

Submodule

Referenzen

1. Michael Haggerty: Git 2.3 has been released (2015), last seen 2024-05-06