Standard-Editor für Git setzen

Wenn das Versionsverwaltungsystem Git im Terminal bzw. auf der Konsole genutzt wird, so wird unter anderem im Falle des Befehls:

git commit

ein Editor geöffnet (in diesem Fall, zur Eingabe der Commit-Nachricht). Der betreffende Editor wird durch die Git-Konfiguration bestimmt. Innerhalb der Konfiguration definiert der Parameter core.editor den zu nutzenden Editor. Um einen Editor zu setzen, z.B. nano muss folgender Befehl genutzt werden:

git config --global core.editor "nano"

Damit wird der Editor nano in der globalen Git-Konfiguration hinterlegt und fortan als Standard-Editor für Git im Terminal genutzt.

Git-Branch ohne History erstellen

Eine wichtige Eigenschaft moderner Versionskontrollsysteme ist die Möglichkeit Branches zu erstellen. Ein neu erstellter Branch stellt aus Anwendersicht eine Kopie des Quellbranches da. Manchmal soll allerdings ein Branch erstellt werden, welcher nicht von der Versionsgeschichte eines Quellbranches beeinflusst ist. Unter Git kann ein solcher Branch mit dem Befehl:

git checkout --orphan branchName

erstellt werden. Dadurch wird ein Branch ohne Elternteil erstellt. Dies wiederum führt dazu das der Branch keinerlei Versionsgeschichte verfügt und unabhängig von anderen Branches des gleichen Repository existiert.

Gogs hinter einem Reverse Proxy betreiben

Gogs ist ein Git-Service welcher eine ähnliche Funktionalität wie der bekannte Dienst GitHub zur Verfügung stellt. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte man ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, kann man hierfür einen Reverse Proxy nutzen. Dafür eignen würde sich zum Beispiel Nginx, der im ersten Schritt auf dem Server installiert werden muss:

apt-get install nginx

Anschließend wird die Konfiguration angelegt:

nano /etc/nginx/sites-available/example

In diesem Fall befasst sich die Konfiguration mit der verschlüsselten Kommunikation per HTTPS und der Weiterleitung von unverschlüsselten Verbindung in Richtung der verschlüsselten Verbindung.

server {
        listen 80;
        listen [::]:80;

        server_name example.com;

        return 301 https://$host$request_uri$is_args$args;
}

server {
    listen 443;
    listen [::]:443 default_server;

    ssl on;
    ssl_certificate        /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.com/privkey.pem;

    server_name example.com;

    client_max_body_size 500m;

    location / {
        proxy_pass https://localhost:3000;
    }
}

Nachdem die Konfiguration für Nginx hinterlegt ist, wird die Standardkonfiguration entfernt und ein symbolischer Link für die neue Konfiguration erstellt. Anschließend wird Nginx neugestartet, damit die geänderte Konfiguration wirksam wird:

rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example
service nginx restart

Nach der Anpassung der Nginx-Konfiguration, muss die app.ini (sie befindet sich im gogs/custom/conf/ Ordner) von Gogs angepasst werden und dort die neue ROOT_URL ohne zusätzlichen Port angegeben werden. Anschließend kann auf Wunsch, per Firewall, der Port 3000 für Zugriffe von außen gesperrt werden.

Aktivieren Sie JavaScript um das Video zu sehen.
Video-Link: https://seeseekey.net/archive/118039

Git Repository mit Submodulen klonen

In der Git Welt existieren sogenannte Submodule. Diese kann man dem Repository hinzufügen und damit ein Git Repository in ein anderes Git Repository einbetten. Nach dem klonen eines solchen Projektes mittels:

git clone git@example.org:seeseekey/project.git

wird man feststellen das sich nur das Hauptprojekt auf der Festplatte befindet. Möchte man die Submodule ebenfalls mit klonen so muss der Parameter recursive zusätzlich übergeben werden:

git clone --recursive git@example.org:seeseekey/project.git

Mit Hilfe des Parameters werden alle Submodule ebenfalls geklont und landen somit auf der Festplatte.

Git und „multiple stage entries“

Wenn man längere Zeit mit Git arbeitet, wird einem die eine oder andere seltenere Fehlermeldung über den Weg laufen. Eine dieser Fehlermeldungen ist:

fatal: multiple stage entries for merged file 'DBAdapter.cs'

Hintergrund bei diesem Problem ist das der Index, welcher die Änderungen und Dateien enthält mit welchem der nächste Commit erstellt wird, für eine Datei mehrere Einträge vorhält; was per Definition nicht der Fall sein sollte. Der Workaround für diese Problem besteht darin, den Index (bzw. die sogenannte Staging area) zu löschen, die Dateien erneut hinzuzufügen und das ganze mit einem Commit in Stein gießen:

rm .git/index
git add -A
git commit -a

Anschließend kann das Git-Repository wieder ohne Probleme genutzt werden.