Git - kurz & gut

KAPITEL 3

Arbeiten mit Git

Hilfe finden

Die Dokumentation von Git ist sehr gut und teilweise auch auf Deutsch verfügbar. Fragen zur Benutzung von Git gehören sicher zu den meistgesuchten im Netz, und es gibt hierzu wahnsinnig viele gute Antworten und Beiträge.

Natürlich hat Git auch auf der Kommandozeile eine Hilfe integriert, git help listet die meistverwendeten Kommandos auf und bietet die Möglichkeit, sich die Dokumentation zu einzelnen Kommandos anzeigen zu lassen.

Bei der täglichen Arbeit ist das Kommando git status extrem hilfreich. Es liefert nicht nur Informationen darüber, was gerade passiert, es bietet auch Hilfestellung an, wenn es darum geht, wie die nächsten Schritte aussehen könnten. Wenn du mal nicht weiterweißt, schau, ob dir die Ausgabe von git status weiterhilft. Im Abschnitt Was hat sich lokal geändert? auf Seite 38 schauen wir uns git status noch einmal detaillierter an.

Viele Git-Aktionen kannst du auch wieder abbrechen. Wenn du also merkst, dass etwas nicht so läuft wie gedacht, solltest du prüfen, ob du das entsprechende Kommando abbrechen kannst. Möglich ist das z.B. beim Merge oder beim Rebase. Das bereits ausgeführte Kommando wird hierzu noch einmal mit dem Flag abort aufgerufen. Dies ist ein Beispiel, in dem das Merge-Kommando abgebrochen wird:

Wenn du das abort-Flag verwendest, ist dein lokaler Stand wieder der gleiche wie vor der Ausführung des Merge-Kommandos.

Das Git-Repository

Das Git-Repository ist die Grundlage allen Arbeitens mit Git. Es ist das Projektverzeichnis, in dem alle Projektdaten sowie die von Git gespeicherten Änderungen abgelegt werden. Am Anfang der Arbeit mit Git steht deshalb immer das Erstellen oder das Herunterladen eines Repositorys. Git-Kommandos lassen sich in der Regel nur in einem Git-Repository ausführen. Wer es außerhalb eines Repositorys versucht, wird eine Fehlermeldung erhalten mit dem Hinweis, dass es sich beim aktuellen Ordner nicht um ein Git-Repository handelt.

Lokal initialisieren

Um aus einem gewöhnlichen Ordner ein Git-Repository zu machen und fortan Änderungen zu verfolgen, wird im betreffenden Ordner folgender Befehl aufgerufen:

Mit Remote-Repositories arbeiten

In aller Regel wird Git benutzt, um gemeinsam mit anderen an einer Codebasis zusammenzuarbeiten. Hier kommen Remote-Repositories ins Spiel.

Was sind Remote-Repositories?

Ein lokales Repository ist durch die Konfigurationsoption remote mit einer Quelle verbunden. Diese Quelle ist ein geteiltes Repository, das heute häufig auf Onlineservices wie GitHub gehostet ist. Es kann aber auch ein Server sein, auf dem Git installiert ist und auf dem das Repository liegt. Obwohl Git einen dezentralen Ansatz verfolgt, wird in den meisten Fällen das Remote-Repository zum »zentralen« Repository.

Abbildung 3-1: Ein Team arbeitet mit einem zentralen Repository.

Exkurs: Mehrere Remote-Repositories

In den meisten Fällen arbeitet ein Entwicklungsteam mit einem Remote-Repository. Eine Ausnahme bildet der Fork-basierte Workflow, der häufig bei der Zusammenarbeit an Open-Source-Projekten eingesetzt wird. Nicht alle, die an einem Open-Source-Projekt mitarbeiten, haben und erhalten Schreibzugriff auf das online bei GitHub oder GitLab gehostete Repository. Beim Fork-basierten Workflow können die Maintainer*innen immer entscheiden, welche Änderungen übernommen werden, und haben die volle Kontrolle. Zudem wäre das User- und Rechtemanagement schlicht viel zu viel Aufwand für die häufig ehrenamtlich betriebenen Projekte.

Wichtig zu wissen: Das Forken ist ein Feature von Git-Onlinediensten wie GitHub. Fork heißt auf Deutsch Gabel oder Verzweigung. Wenn du einen Fork erstellst, kopierst du ein bestehendes Repository in deinen persönlichen GitHub-Account. In dieser Kopie des Repositorys kannst du Änderungen durchführen und diese in dein eigenes Remote-Repository pushen. Das geschieht völlig isoliert vom ursprünglichen Projekt. Änderungen, die im ursprünglichen Repository passieren, kannst du durch die Konfiguration eines zweiten Remote-Repositorys weiterhin abrufen. Wenn alles fertig ist, erstellst du aus dem Fork heraus einen Änderungsvorschlag für das Repository des Open-Source-Projekts. Ein solcher Änderungsvorschlag wird in der GitHub-Terminologie Pull-Request genannt. Die folgende Grafik illustriert die Verwendung der beiden Remote-Repositories. Wir schauen uns in Kapitel 5, Typische Git-Workflows, noch einmal genauer an, wie das Arbeiten mit einem Fork in der Praxis funktioniert.

Abbildung 3-2: Beim Fork-basierten Workflow gibt es zwei Remote-Repositories: das Original-Repository und den Fork – also die Kopie – in deinem GitHub-Account.

Ein Repository kopieren

Um ein existierendes Repository zum ersten Mal auf den eigenen Rechner zu kopieren, wird das Kommando git clone verwendet. Es kopiert das Repository in einen neuen Ordner, der von Git erstellt wird und den Namen des Repositorys trägt. Das Kommando git clone versieht das Repository außerdem mit einer spezifischen Konfigurationseinstellung, die auf das Quell-Repository zeigt. Diese Konfiguration wird remote genannt. Eine Remote-Konfiguration wird immer mit einer Kurzbezeichnung versehen. Falls es mehrere Remote-Konfigurationen gibt, kannst du sie so leichter auseinanderhalten. Per Default verwendet Git die Kurzbezeichnung origin.

Das Herunter- und Hochladen eines Repositorys ist grundsätzlich durch die Protokolle git, SSH, HTTP und HTTPS möglich. Die meisten Onlinedienste wie GitHub oder GitLab unterstützen die sichereren Protokolle HTTPS und SSH. HTTPS ist einfach zu benutzen, und die durch das Protokoll verwendeten Ports werden in der Regel nicht durch Firewalls blockiert.

Im folgenden Beispiel wird ein Repository, das auf GitHub gehostet ist, geklont.

Bei den gängigen Git-Onlinediensten findest du die URL, um das Repository zu klonen, in der Regel unter den Menüpunkten Code oder Download.

Arbeitest du mit weiteren Entwickler*innen zusammen an einem gemeinsamen Repository, laden diese ständig Änderungen in das Repository hoch. Diese Änderungen musst du dir immer wieder durch den Befehl git pull herunterladen. Wir schauen uns das Kommando später noch genauer an. Wichtig ist jetzt: Bei jedem Herunterladen musst du dich immer erneut authentifizieren. Wird das Repository bei GitHub gehostet und hast du HTTPS verwendet, musst du stets deinen Benutzernamen und dein Passwort neu angeben. So wird sichergestellt, dass du auch wirklich die Berechtigung hast, das Repository herunterzuladen. Auch wenn du Änderungen in ein Repository hochlädst, ist das der Fall.

In einigen Firmen und Projekten ist die Verwendung von Zwei-Faktor-Authentifizierung Pflicht. Das wird auch von den Onlinediensten angeboten. Bei GitHub ist es dann z.B. notwendig, für die Authentifizierung einen Personal Access Token im Profil zu generieren und diesen für die Authentifizierung zu verwenden.

Alternativ zur Verwendung von HTTPS kann ein Repository per SSH geklont werden.

Da SSH auf einem Public-Key-Verschlüsselungsverfahren beruht, benötigst du ein Schlüsselpaar, um SSH zu nutzen. Dieses Schlüsselpaar besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel ist geheim und wird mit niemandem geteilt. Der öffentliche Schlüssel wird auf einem Server oder bei einem Service wie GitHub hinterlegt, und du kannst dich dann mit deinem privaten Schlüssel authentifizieren. Welche Schritte hierzu nötig sind, beschreibt der folgende Hinweis »SSH-Key erstellen und bei GitHub hinterlegen«.