Git für Einsteiger

Dies ist der allererste Blogbeitrag unserer neuen Praktikanten im Bereich Softwareentwicklung—Daniel, Simon und Till. Wir würden uns über euer Feedback freuen!

Git ist ein Open-Source-Versionskontrollsystem, das zum Speichern und Verwalten von Code, zur Pflege verschiedener Versionen des Programms, zum Teilen und zur Zusammenarbeit mit anderen sowie zur Wiederherstellung verlorenen oder beschädigten Codes verwendet wird. Während es eine Vielzahl von Funktionalitäten und Optionen bietet, sind nur wenige grundlegende Befehle erforderlich, um die häufigsten Arten von Operationen auszuführen und schnell produktiv zu werden.

Hinweis: Sie finden die offizielle Dokumentation unter git-scm.com/docs.

Die Voraussetzungen

Bevor Sie Git verwenden können, müssen Sie es auf Ihrem Computer installieren. Die Installationsanweisungen für Ihr Betriebssystem finden Sie unter git-scm.com/downloads. Im Allgemeinen wäre ein guter Ausgangspunkt:

• Git installiert
• Ein Kommandozeilentool zum Ausführen von Git-Befehlen, wie z.B. Git Bash
• Grundkenntnisse über die Verwendung der Kommandozeile zur Navigation im Dateisystem

Bevor wir mit dem Erstellen unseres ersten Repositories beginnen, müssen wir unser Git-Benutzerprofil konfigurieren. Dieses wird später in Commits angezeigt, um zu verfolgen, welcher Benutzer eine bestimmte Änderung vorgenommen hat. In unserer Kommandozeile führen wir die folgenden Befehle aus (ersetzen Sie Ihre eigene E-Mail und Ihren Namen):

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Dann können wir überprüfen, ob die Konfiguration erfolgreich war, indem wir ausführen:

git config --list

Dies sollte den Benutzernamen und die E-Mail-Adresse anzeigen, die wir gerade festgelegt haben.

Terminologie

Bevor wir beginnen, lassen Sie uns einige Begriffe klären:

• Repository: Ein Repository ist ein Verzeichnis, das alle Dateien und Ordner Ihres Projekts sowie die Historie aller daran vorgenommenen Änderungen enthält.
• Commit: Ein Commit ist ein Schnappschuss des Repositories zu einem bestimmten Zeitpunkt. Es enthält alle seit dem letzten Commit vorgenommenen Änderungen an den Dateien und Ordnern.
• Branch: Ein Branch ist eine separate Entwicklungslinie in einem Repository. Er ermöglicht es Ihnen, an verschiedenen Funktionen oder Fehlerbehebungen zu arbeiten, ohne den Hauptcode zu beeinträchtigen.
• Remote: Ein Remote ist eine auf einem Server gehostete Version Ihres Repositories, wie z.B. GitHub oder GitLab. Es ermöglicht Ihnen, mit anderen zusammenzuarbeiten und Ihren Code zu teilen.
• Clone: Ein Repository zu klonen bedeutet, eine lokale Kopie eines Remote-Repositories auf Ihrem Computer zu erstellen. Dies ermöglicht es Ihnen, lokal an dem Code zu arbeiten und Änderungen an das Remote zurückzuschieben.
• Push: Pushing ist der Prozess des Hochladens Ihrer lokalen Änderungen in ein Remote-Repository. Dies ermöglicht es anderen, Ihre Änderungen zu sehen und mit daran zu arbeiten.
• Pull: Pulling ist der Prozess des Herunterladens von Änderungen aus einem Remote-Repository auf Ihre lokale Kopie. Dies ermöglicht es Ihnen, mit den neuesten Änderungen, die von anderen vorgenommen wurden, auf dem Laufenden zu bleiben.
• Merge: Merging ist der Prozess, Änderungen von einem Branch in einen anderen zu integrieren. Dies ermöglicht es Ihnen, neue Funktionen oder Fehlerbehebungen in den Hauptcode zu integrieren.
• Conflict: Ein Konflikt tritt auf, wenn zwei Branches Änderungen an derselben Codezeile vorgenommen haben. Git wird Sie auffordern, den Konflikt zu lösen, bevor Sie einen Merge durchführen können.
• Working Directory: Das Arbeitsverzeichnis ist die lokale Kopie Ihres Repositories, in der Sie Änderungen an Dateien vornehmen. Es enthält alle Dateien und Ordner Ihres Projekts.
• Fork: Ein Fork ist eine Kopie eines Repositories, die es Ihnen ermöglicht, Änderungen vorzunehmen, ohne das Originalrepository zu beeinträchtigen. Es wird häufig in Open-Source-Projekten verwendet, um Änderungen beizutragen.
• Pull Request: Ein Pull Request ist eine Anfrage, um Änderungen von einem Branch oder Fork in einen anderen zu integrieren. Er ermöglicht es anderen, die Änderungen zu überprüfen und zu diskutieren, bevor sie integriert werden.
• Cherry-pick: Cherry-picking ist der Prozess, einen bestimmten Commit von einem Branch auf einen anderen anzuwenden. Es ermöglicht Ihnen, selektiv Änderungen anzuwenden, ohne ganze Branches zu integrieren.
• Checkout: Einen Branch oder Commit auszuchecken bedeutet, in Ihrem Arbeitsverzeichnis zu diesem Branch oder Commit zu wechseln. Es ermöglicht Ihnen, an verschiedenen Funktionen oder Fehlerbehebungen zu arbeiten.

Ein Repository erstellen: git init

Der init-Befehl verwandelt das aktuelle Verzeichnis in ein neues Git-Repository. Lassen Sie uns zuerst zu einem Ordner navigieren, den wir in ein Repository umwandeln möchten, und den Befehl ausführen:

git init

Das gewählte Verzeichnis sollte nun einen einzelnen Ordner '.git' enthalten, der alles enthält, was Git benötigt, um Änderungen in diesem Verzeichnis zu verfolgen und Branches zu verwalten (der Ordner ist versteckt und wird möglicherweise in Ihrem Betriebssystem standardmäßig nicht angezeigt). Für den Moment ist dies nur ein lokales Repository, da es noch nicht mit einer Remote-Git-Speicherung wie GitHub, GitLab oder ähnlichem verbunden wurde.

Ein Repository klonen: git clone

Anstatt unser eigenes neues Repository zu initialisieren, können wir auch den Klonbefehl verwenden, um eine Kopie eines vorhandenen Repositories herunterzuladen. In einem neuen leeren Verzeichnis führen wir zum Beispiel aus:

git clone https://github.com/golang/go.git

Dies wird eine lokale Kopie des Golang-Repositories mit all seinen Branches erstellen. Die URL kann auf der Hauptseite des Repositories gefunden und per Klick auf die grüne "Code"-Schaltfläche kopiert werden. Das Klonen kann auch mittels SSH erfolgen, wenn Sie SSH-Schlüssel für Ihr GitHub-Konto eingerichtet haben. In diesem Fall sieht die URL anders aus.

Einen Commit vorbereiten: git add

Lassen Sie uns zu unserem ersten Verzeichnis zurückkehren und eine neue Datei erstellen:

touch test.txt
echo "Hello World!" > test.txt

Wenn wir nun den Befehl git status ausführen, um den aktuellen Zustand unseres Repositories zu sehen, werden wir feststellen, dass die Datei nicht nachverfolgt wird. Dies bedeutet, dass Git sie noch nicht kennt und sie noch nicht im nächsten Commit enthalten sein wird:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        test.txt

Wir haben Git noch nicht mitgeteilt, welche Dateien es nachverfolgen soll. Um unsere neu erstellte Textdatei nachzuverfolgen, können wir ausführen:

git add test.txt

– oder wenn wir faul sind und einfach alles im Verzeichnis auf einmal hinzufügen möchten, könnten wir git add . verwenden, um rekursiv alles Neue oder Geänderte im Verzeichnis und seinen Unterverzeichnissen hinzuzufügen.

Wenn wir jetzt git status erneut ausführen, werden wir feststellen, dass die Datei jetzt für den Commit bereitgestellt wurde:

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   test.txt

Die Datei wurde bereitgestellt, d.h. sie wurde zur Aufnahme in eine neue Version/Revision unseres Repositories vorgemerkt, aber noch nicht committet.

Änderungen committen: git commit

Wir verwenden den Commit-Befehl, um alle unsere bereitgestellten Änderungen zu nehmen und einen neuen Commit zu erstellen, im Wesentlichen ein Schnappschuss des aktuellen Zustands unseres Projekts, auf dem wir aufbauen und zu dem wir möglicherweise später zurückkehren können. Lassen Sie uns dies jetzt in unserem Repository tun:

git commit

Wenn keine Optionen angegeben sind, wird Git den konfigurierten Standard-Editor öffnen, um eine Commit-Nachricht zu schreiben. Hier könnten wir einen Titel und eine Beschreibung unterhalb der kommentierten Zeilen wie folgt hinzufügen:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
#
# Initial commit
#
# Changes to be committed:
#	new file:   test.txt
#
Added test.txt to the repo

This is the description, explaining the commit in more detail.
Anyone else reading this should be able to tell
what the commit contains and why it was made.

Üblicherweise sollte die erste Zeile der Titel sein, ein einzelner Satz, der erklärt, worum es in dem Commit geht. Der folgende Text, getrennt durch eine Leerzeile, kann verwendet werden, um den Commit weiter zu beschreiben und zu erklären. Lassen Sie uns die Datei speichern und dann schließen. Git sollte dies erkennen und den Commit erstellen.

Hinweis: Wenn wir den Standardeditor ändern möchten, z.B. in VS Code, können wir dies tun, indem wir git config --global core.editor "code --wait" ausführen. Andere Editoren können auf ähnliche Weise eingestellt werden, z.B. git config --global core.editor "nano" für nano oder git config --global core.editor "vim" für vim.

Das Remote-Repository: git remote

An diesem Punkt existiert unser Repository noch immer nur auf unserem lokalen Rechner. Aus Gründen der Sicherung und Zusammenarbeit möchten wir unser Repository möglicherweise auf einer Online-Plattform pflegen. Für dieses Beispiel verwenden wir GitHub, aber jede Alternative wie GitLab oder Bitbucket funktioniert ebenfalls, solange Sie einen funktionierenden Link und Zugang zu einem Online-Repository haben.

Nehmen wir an, wir haben ein neues Repository unter https://github.com/gentlent/test_project.git eingerichtet. Wir können nun den Remote-Befehl ausführen, um unser lokales Repository mit dem Remote zu verbinden:

git remote add origin https://github.com/gentlent/test_project.git

Anschließend verwenden wir git remote -v, um zu überprüfen. Es sollte `origin` gefolgt von unserer URL anzeigen.

Änderungen pushen: git push

Wir sind nun bereit, unseren zuvor erstellten Commit in das neue Remote-Repository zu pushen und mit ihm zu synchronisieren. Lassen Sie uns ein git push mit einigen Flags ausführen—origin ist der Standardname für unser Remote, und main ist unser eigener Branch-Name:

git push -u origin main

Hinweis: Der Standard-Branch-Name war früher master. Viele Plattformen verwenden heutzutage standardmäßig main. Wenn der obige Befehl einen Fehler verursacht, überprüfen Sie Ihren Branch-Namen mit git status.

Die Verwendung der -u-Optionsflagge bewirkt, dass Git den lokalen Branch mit dem Remote-Repository verknüpft. Jeder zukünftige push-Befehl wird automatisch von main nach origin/main gepusht, ohne dass wir die Ziele angeben müssen. Wenn wir unser Remote-Repository auf GitHub überprüfen, können wir jetzt sehen, dass unsere Textdatei hochgeladen wurde.

Änderungen pullen: git pull

Wenn wir Änderungen an unserem Remote-Repository vorgenommen haben, können wir sie mit dem git pull-Befehl in unser lokales Repository ziehen. Dies lädt alle Änderungen, die am Remote-Repository vorgenommen wurden, herunter und integriert sie in unsere lokale Kopie. Wenn wir zum Beispiel Änderungen an der test.txt-Datei auf GitHub vorgenommen haben, können wir ausführen:

  git pull

Dies wird die Änderungen herunterladen und in unsere lokale Kopie des Repositories integrieren. Wenn es Konflikte gibt, wird Git uns auffordern, diese zu lösen, bevor der Pull abgeschlossen wird. Wenn wir dies jetzt tun, erhalten wir die Nachricht Bereits aktuell, da Git festgestellt hat, dass keine neuen Änderungen vorgenommen wurden und das Zusammenführen übersprungen wurde.

---

Das obige deckt ein Minimum an Funktionalität ab, um mit dem Git-Ökosystem zu interagieren. Es gibt viele weitere nützliche Befehle, insbesondere im Hinblick auf die Verwaltung verschiedener Branches, die hier nicht erklärt werden. Eine vollständigere Liste von Befehlen und deren Beschreibungen finden Sie in der offiziellen Dokumentation unter git-scm.com/docs oder indem Sie sie in Ihrer Kommandozeile ausprobieren. Wenn Sie jemals eine Frage zu einem Befehl haben, können Sie git help <command> ausführen, um eine kurze Beschreibung dessen zu erhalten, was er bewirkt und wie man ihn verwendet.