Versionsverwaltung mit Git

Während deiner Ausbildung hast du bestimmt schon einmal zusammen mit anderen an einem Softwareprojekt gearbeitet. Dabei habt ihr gleichzeitig Code geschrieben und musstet ihn zu einer funktionierenden Software zusammenführen.

Doch das ist gar nicht so leicht: Alle arbeiten an ein und demselben Code. Werden die Änderungen nicht regelmäßig mit dem Team geteilt, kann es passieren, dass verschiedene Teile der Software nicht mehr zusammen passen und sie nicht korrekt funktioniert. Dabei stellt sich die Frage: Wie tauscht sich ein Team über Änderungen im Code am besten aus? Gibt es eine Möglichkeit, eine aktuelle Version des Quellcodes mit anderen zu teilen? Die gibt es, und zwar mithilfe des Versionsverwaltungssystems Git.

simpleclub zeigt dir, wie du mithilfe von Git deinen Quellcode verwaltest, mit anderen Entwicklern austauschst und wie du damit effizient im Team arbeitest.

Versionsverwaltung mit Git einfach erklärt

Kyra arbeitet mit ihrem Kollegen Louis an einem Softwareprojekt. Sie bearbeiten denselben Code. Daher ist es wichtig, dass jede Änderung, die einer der beiden vornimmt, schnell beim anderen ankommt.

Sie verwenden dazu das Versionsverwaltungssystem Git. Du kannst dir die Arbeit mit Git im Wesentlichen folgendermaßen vorstellen:

Kyra und Louis haben auf ihrem Rechner jeweils eine Version des Softwarecodes, die sie bearbeiten. Die vorgenommenen Änderungen laden sie in einem Online-Speicher hoch. Der jeweils andere kann sich daraus die Änderungen herunterladen, in seine aktuelle Version des Quellcodes einfügen und mit der aktualisierten Version weiterarbeiten.

Die Verwendung eines Versionsverwaltungssystems erlaubt Teams, effizient an einem Softwarecode zu arbeiten. Änderungen von Teammitgliedern können nachvollzogen, analysiert und gegebenenfalls rückgängig gemacht werden.

Definition Versionsverwaltung mit Git

Erklärung Versionsverwaltung mit Git

Bevor du mit Git startest, musst du dich mit dem Grundkonzept von Git vertraut machen. Da die Fachsprache der Informatik Englisch ist, lernst du auch hier viele englische Begriffe kennen.

Zu den wichtigsten Konzepten gehören

• Die Speicherorte des Quellcodes, Repositories (deutsch Lagerstätte) genannt.
• Die Durchführung von Änderungen in einem Repository.
• Erstellung von Abzweigungen von der Hauptfassung des Codes, sogenannte Branches.

Speicherung von Code in Repositories

Der Kern von Git ist die Arbeit mit Repositories. In einem Repository liegt immer eine aktuelle Version des Softwarecodes sowie die Historie der Veränderungen. In der Praxis wird auch häufig abgekürzt von einem Repo gespochen.

Es gibt zwei Arten von Repositories:

1. Ein lokales Repository liegt nur auf deinem Computer. Es ist nur für dich zugänglich.
2. Ein remote (deutsch entferntes) Respository ist ein Online-Speicher, auf den du und deine Teamkollegen Zugriff haben. Es ist eine Kopie deines lokalen Repositories.

Du kannst dich entscheiden, ob du nur ein lokales oder beide Arten von Repositories verwenden willst. Das lokale Repository eignet sich nur, wenn du alleine an einem Projekt arbeitest. Sobald du mit anderen Leuten zusammen arbeitest oder du dein Projekt vor einer Löschung sichern willst, solltest du sowohl ein lokales als auch ein remote Repository wählen.

Nach der Installation von Git auf deinem Computer kannst du ein lokales Repository erstellen. Möchtest du ein remote Repository hinzunehmen, musst du dich bei einem Dienstleister registrieren, welcher den Online-Speicher zur Verfügung stellt. Gängige Anbieter sind z. B. GitHub, GitLab oder Bitbucket.

Änderungen in Repositories festhalten

Stell dir nun vor, du hast den Softwarecode an deinem PC verändert, z. B. indem du ein neues Feature implementiert hast. Du möchtest, dass diese Änderungen in der aktuellen Version des Softwarecodes festgehalten werden.

Wichtig ist: Die vorgenommenen Änderungen sind noch in keinem Repository sichtbar. Sie sind zunächst einmal in deinem Working Directory (deutsch Arbeitsverzeichnis) gespeichert. Du musst erst aktiv entscheiden, welche Änderungen in das lokale Repository aufgenommen werden sollen.

Sobald du die Änderungen ausgewählt hast, überführst du sie in das lokale Repository. Die Überführung wird als (lokaler) Commit (deutsch Schnappschuss) bezeichnet.

Verwendest du auch ein remote Repository, kannst du deine lokalen Commits in dieses überführen. Der Vorgang wird als Push (deutsch Stoß) bezeichnet.

Der Vorgang mag auf den ersten Blick umständlich erscheinen: Warum kannst du nicht einfach in deiner Entwicklungsumgebung auf „Speichern" klicken und die Änderungen landen sofort in deinem lokalen Repo? Dafür gibt es mehrere Gründe:

• Der Grundsatz „Auf einem Repository liegt immer eine funktionierende Version des Codes": Du hast sicherlich schon einmal länger an einem Stück Code gearbeitet und musstest die Änderungen wieder löschen, weil es doch nicht funktioniert hat. Hätte jede Zwischenspeicherung einen Commit durchgeführt, wäre dieser Grundsatz vorübergehend verletzt gewesen.
• Schlechte Übersicht durch zu viele Commits: Ein Repo ist eine Sammlung von Änderungen am Code. Würde bei jeder Zwischenspeicherung in der Entwicklungsumgebung ein Commit durchgeführt werden, hättest du bald keine Übersicht mehr über den genauen Verlauf der Software. Ausgewählte Commits schaffen Klarheit und Übersicht über die Historie der Software.

Branches in Git

Implementiert ein Entwickler ein neues Feature, ist es üblich, dass er dafür einen neuen Branch (deutsch Ast) erstellt. Du kannst dir das wie eine Abzweigung von der Hauptfassung vorstellen. All deine Commits werden auf diesem Ast durchgeführt, bis du dich dafür entscheidest, alle Änderungen auf einmal in die Hauptfassung des Codes zu übernehmen.

Der Hauptast eines Repos wird als master-Branch bezeichnet. Er wird automatisch zusammen mit dem Repository erstellt, d.h. sowohl das lokale als auch das remote Repository haben einen master-Branch. Der Branch, den du eigens für die Implementierung eines Features erstellst, wird als Feature Branch bezeichnet.

Arbeit mit Git

Nachdem du nun mit den wichtigsten Konzepten von Git vertraut bist, lernst du, wie du das Versionskontrollsystem genau verwendest.

Du verwendest Git üblicherweise über die Kommandozeile deines Computers. Dabei nutzt du Git-Befehle, auch Commands genannt. Jeder Command beginnt mit dem Wort git, gefolgt von einem oder mehreren Schlüsselwörtern. Bei einigen Befehlen musst du zudem noch weitere Informationen angeben, z. B. eine URL. Diese Informationen werden Parameter genannt. In der allgemeinen Form eines Befehls wird ein Parameter in spitzen Klammern angegeben. Ein Beispiel ist git clone , bei dem du „" mit einer passenden URL ersetzt. Der clone-Befehl wird später nochmal genauer erklärt.

Du bestätigst die Eingabe eines Commands mit Enter. Git gibt dir eine Antwort in Textform, die in der Kommandozeile direkt unter dem Befehl erscheint.

Die wichtigsten Git-Befehle werden dir hier vorgestellt. Beachte, dass du sie immer im Kontext des Ordners deines Projektes eingibst. Wenn du Linux oder MacOS verwendest, navigierst du dazu über die Kommandozeile zum Projektordner und führst dort die Befehle aus. In Windows kannst du per Rechtsklick auf den Projektordner das Programm Git-Bash starten. Dabei wird die Kommandozeile direkt im Projektordner geöffnet. Nur die Konfiguration von Git im ersten Punkt kann außerhalb eines Projektordners stattfinden.

Konfiguration von Git

Nachdem du Git über die offizielle Website heruntergeladen und installiert hast, musst du es konfigurieren. Du hast die Auswahl aus vielen verschiedenen Optionen. Die wichtigste und für den Anfang vollkommen ausreichende ist das Setzen deines Benutzernamen und E-Mail-Adresse.

Dazu benötigst du die folgenden beiden Befehle:

Den Benutzernamen kannst du dabei frei wählen.

Nun werden alle Commits und sonstige Aktionen in deinen Repositories mit deinem Namen versehen. Somit können deine Teamkollegen zum Beispiel nachvollziehen, wer welche Änderungen durchgeführt hat.

Es ist zudem empfehlenswert, einen SSH-Schlüssel zu erstellen. Du kannst damit eine sichere Verbindung zwischen deinem PC und dem Server, auf dem dein remote Repo liegt, authentifizieren. Git kann SSH-Schlüssel anstelle der üblichen Passwortverifizierung verwenden, wenn du Änderungen auf das remote Repository übertragen oder von dort herunterladen willst.

Erstellung eines lokalen Repositorys

Du hast zwei Möglichkeiten, ein lokales Repository auf deinem PC zu erstellen.

1. Ein bereits bestehendes Projekt auf deinem Computer in ein Repository umwandeln.
2. Ein remote Repository auf deinen PC kopieren (auch klonen genannt).

Im ersten Fall führst du den folgenden Befehl im Projektordner aus:

Auch im zweiten Fall öffnest du die Kommandozeile an dem Ort, an den du das remote Repository klonen willst. Für den Klon-Vorgang benötigst du die URL des remote Repositorys. Diese kannst du bei dem Anbieter deines remote Repositorys kopieren.

Um nun das Repository zu klonen, tippst du folgenden Befehl in die Kommandozeile ein.

Durch das Klonen hast du sowohl ein lokales Repository auf deinem PC erstellt als auch eine Verbindung zwischen dem lokalen und dem remote Repository hergestellt.

Verbindung zu remote Repository herstellen

Hast du nur ein lokales Repo auf deinem PC und möchtest zusätzlich ein remote Repo, musst du dieses zunächst bei einem Anbieter deiner Wahl erstellen. Du kopierst anschließend die URL des remote Repositorys und tippst in die Kommandozeile folgenden Befehl ein.

Das Wort „origin" im Befehl ist die Bezeichnung für das remote Repository. Du kannst es auch einen anderen Namen geben, jedoch hat sich in der Praxis dieser Name durchgesetzt.

Du hast nun eine Verbindung zwischen deinem lokalen und dem remote Repository hergestellt. Du kannst ab jetzt Änderungen, die du an deinem lokalen Repository vornimmst auch an das remote Repository „schicken".

Commits im lokalen Repository durchführen

Stell dir vor, du möchtest nun mit der Implementierung deines ersten Features starten. Dazu erstellst du einen neuen Feature-Branch und wechselst auf ihn. Das bedeutet, dass du die „Abzweigung" zum Feature-Branch genommen hast und von nun an alle Commits auf diesem ausführst. Wie das im Detail passiert, lernst du weiter unten.

Nach einiger Arbeit bist du bereit und möchtest deinen ersten Commit (also Änderung) an deinem Repository vornehmen. Dabei folgst du eigentlich immer demselben Ablauf:

1. Anzeige aller veränderten Dateien.

Die Antwort auf folgenden Befehl liefert dir unter anderem eine Liste an Dateien, die du verändert hast.

Beachte, dass diese Änderungen ausschließlich in deinem Working directory, nicht aber in deinem Repository gespeichert sind.

2. Auswahl der Dateien, die in das Repo übernommen werden sollen

Mit dem folgenden Befehl kannst du eine Datei auswählen, deren Änderung in das Repo überführt werden sollen.

Du kannst diesen Befehl so oft eintippen, bis du alle gewünschten Dateien ausgewählt hast. Alternativ kannst du den Befehl

ausführen, der alle veränderten Dateien auswählt.

Der Befehl heißt add, da du die Dateien zu einer Art Sammelplatz hinzufügst. Dieser wird in der Fachsprache als Staging Area bezeichnet. Sobald du den Sammelplatz mit den gewünschten Dateien gefüllt hast, kannst du die Änderungen in das Repository übernehmen.

3. Änderungen in das lokale Repository übernehmen

Zur Erinnerung: Dieser Vorgang wird als die „Ausführung eines Commits" bezeichnet. Dabei gibst du immer eine Commit-Message an. Das ist eine sehr kurze Beschreibung der Änderungen, die du vorgenommen hast, z. B. welches neue Feature du implementiert hast. Der Befehl lautet:

Beachte hier die Anführungszeichen, zwischen denen du die Commit-Message schreibst.

Der Commit wurde nun in deinem Feature Branch durchgeführt. Auf dem master ist er noch nicht sichtbar.

Arbeit mit einem remote Repository

Arbeitest du mit einem remote Repository, kannst du deine lokalen Commits auf das remote Repository übertragen. Da deine lokalen Commits auf deinem Feature-Branch liegen und das remote Repo eine Kopie des lokalen Repos ist, musst du zunächst den Feature Branch auch im remote Repo anlegen. Wie das funktioniert, lernst du im Abschnitt über Branches. Du kannst an dieser Stelle davon ausgehen, dass der Feature-Branch auch im remote Repository vorhanden ist.

1. Änderungen an das remote Repo übertragen

Um nun deine Änderungen im lokalen Repository mit deinen Kollegen auszutauschen, veröffentlichst du deinen Commit auch im remote Repository. Dazu tippst du ganz einfach diesen Befehl ein:

Damit wird dein Commit mitsamt der Commit-Message an das remote Repository namens origin geschickt und ist auf dem angegebenen Branch sichtbar.

2. Änderungen vom remote Repo herunterladen

Möchte sich nun ein Kollege die aktuelle Version eines Branches in sein lokales Repository herunterladen, genügt folgender Befehl:

Unterschied zwischen clone- und pull-Befehl

Der clone- und der pull-Command sind auf dem ersten Blick sehr ähnlich. Sie unterscheiden sich allerdings in wesentlichen Punkten:

• Beim clone-Befehl wird ein bestehendes remote Repo auf deinen lokalen PC kopiert. Dabei werden sowohl ein lokales Repo als auch Die Verbindung zwischen lokalem und remote Repo erstellt. Du benötigst den clone-Befehl also nur einmal.
• Der pull-Command hingegen holt Änderungen, also Commits deiner Teamkollegen, aus dem remote Repo in dein lokales Repo. Dazu musst du bereits ein bestehendes lokales Repo sowie die Verbindung zum remote Repo hergestellt haben.

Hier sind noch einmal alle Befehle zusammengefasst, mit denen du Commits durchführen oder Daten aus remote Repositories herunterladen kannst. Zur besseren Übersicht sind keine Paramter angegeben.

Verwendung von Branches

Wie bereits weiter oben erwähnt, ist es üblich, bei der Entwicklung eines neuen Features einen Feature-Branch zu erstellen. Aber warum solltest du den Umweg über einen extra Branch machen, wenn du direkt auf den master „committen" oder „pushen" könntest? Zwei Gründe sind:

• Es soll immer eine vollständig funktionierende Version des Projekts im master-Branch liegen. Implementierst du ein umfangreiches Feature, machst du zur Sicherung mehrere Commits. Bevor du sie aber auf den Master-Branch überträgst, muss dein neues Feature ausgiebig getestet werden.
• Du kannst mehrere Branches erstellen und dasselbe Feature auf unterschiedliche Weise implementieren. Somit kannst du die verschiedenen Umsetzungen vergleichen und die beste übernehmen.

Du kannst Branches lokal erstellen und sie daraufhin in dein remote Repo übertragen. Zunächst lernst du, wie du mit Branches arbeitest, wenn du nur ein lokales Repository verwendest. Anschließend lernst du einen typischen Arbeitsablauf bei der Arbeit mit Branches in remote Repositories kennen.

Branches im lokalen Repo

1. Neuen Branch erstellen

Mit dem folgenden Befehl erstellst du einen neuen Branch:

Branches werden üblicherweise mit dem Namen oder der Nummer des Features benannt, für das sie erstellt werden.

2. Auf Branch wechseln

Hast du einen Feature-Branch erstellt und willst auf ihm Commits durchführen, musst du auf den neuen Branch wechseln. Dies bedeutet, dass du die „Abzweigung" zum neuen Branch nimmst. Dazu verwendest du diesen Befehl:

Du kannst nun Commits auf dem Feature-Branch durchführen. Wie bereits oben erwähnt, sind diese Commits nur in deinem neuen Branch sichtbar, nicht aber im master.

3. Branches zusammenführen

Stell dir nun vor, du hast das neue Feature fertig implementiert und getestet. Es ist jetzt bereit, in den master-Branch übernommen zu werden. Dazu musst du deinen Feature-Branch und den master-Branch zusammenführen. In der Fachwelt wird dabei von einem Merge gesprochen.

Dazu gehst du wie folgt vor:

1. Du wechselst zurück auf den master-Branch.
2. Du führst den Merge-Prozess durch.

Die Befehle dazu lauten:

Der Parameter Branchname ist dabei natürlich der Name des Feature-Branches.

Branches im remote Repo

Du hast nun gelernt, wie du mit Branches arbeitest, wenn du nur ein lokales Repository verwendest. Üblicherweise arbeitest du aber in einem Team und einem remote Repo.

1. Lokale Branches und Commits in das remote Repo übertagen

Mit dem Befehl

überträgst du deinen lokal erstellten Branch in das remote Repository. Den Befehl benötigst du allerdings nur einmal zur Übertragung des Branches in das remote Repo. Ab jetzt kannst du Commits auf diesem Branch auch in das remote Repo überführen. Dazu verwendest du den weiter oben kennengelernten Befehl

Es ist üblich, dass mehrere Kollegen gleichzeitig verschiedene Branches erstellen.

2. Branch mit master zusammenführen

Stell dir vor, du hast das Feature fertig implementiert, fleißig Commits ausgeführt und diese auf das remote Repo übertragen. Deine Änderungen sind nun bereit, in die Hauptfassung des Codes, also in den master-Branch, übertragen zu werden.

Bevor du jedoch mit dem Merge in den master beginnen kannst, erstellst du eine Merge request. Dies kannst du in der Regel direkt über die Oberfläche des Anbieters erledigen. Du fragst damit an, deinen Branch in den master zu „mergen".

Da du zusammen mit anderen an einem Code arbeitest, ist es üblich, dass während deiner Arbeit am Branch die Hauptfassung des Codes verändert wurde. Es ist möglich, dass diese Veränderungen nicht mit deinen zusammen passen: Zum Beispiel könnten du und ein Kollege dieselbe Zeile Code bearbeitet haben. Welche Zeile sollte nun in den master übernommen werden? Diese Unklarheiten werden als Mergekonflikt bezeichnet und werden dir beim Erstellen der Merge request angezeigt.

Tritt ein Mergekonflikt auf, kannst du diesen lokal lösen. Dazu gehst du wie folgt vor:

1. Du wechselt in deinem lokalen Repo zurück auf den master.
2. Du holst dir die aktuelle Fassung des master per pull-Command.
3. Du übernimmst die Änderungen des masters in deinen lokalen Branch. Dazu wechselst du zurück auf deinen Branch und führst git merge master aus.
4. Git zeigt dir an, dass ein Mergekonflikt aufgetreten ist. Diesen kannst du zum Beispiel direkt über deine Entwicklungsumgebung oder über spezielle Merge-Tools lösen.
5. Sobald der Konflikt gelöst ist, führst du einen lokalen Commit auf deinem Branch durch und überführst ihn in das remote Repo.
6. Die Merge request hat sich verändert und zeigt keinen Konflikt mehr an.

Einer deiner Kollegen kann deinen Code nun ausgiebig prüfen und der Merge request stattgeben.

Git Best Practice

Du hast nun die Grundlagen von Git kennengelernt. Um gleich so effizient wie möglich mit deinen Kollegen zusammenzuarbeiten, solltest du noch ein paar Tipps beherzigen.

• Verfasse aussagekräftige Commit-Messages: Auch wenn sie so kurz wie möglich sein sollten, helfen sie deinen Kollegen deine Arbeit nachzuvollziehen.
• Führe regelmäßige kleine Commits aus: Commits sollten nur einen geringen Umfang haben, z. B. die Implementierug eines Features oder die Behebung eines Fehlers. Das macht die Commit-Historie übersichtlicher.
• Verwende Branches pro Feature: Auch wenn das zusätzliche Arbeit bedeutet, halten sie die Commit-Historie vom master-Branch sauber. Erst wenn eine Änderung vollständig getestet ist, werden sie in den master überführt. Damit wird vermieden, dass inkorrekter Code in der Hauptfassung landet.

Zusammenfassung Versionsverwaltung in Git

Git ist eine Versionsverwaltungssoftware, mit der du verschiedene Fassungen deines Quellcodes vergleichen und Änderungen nachvollziehen kannst. Es erlaubt Teams, effizient an einer Software zu arbeiten und Änderungen schnell auszutauschen.

Bei Git werden die Versionen des Codes in Repositories gespeichert. Es gibt lokale und remote Repositories, wobei das remote Repository eine Kopie des lokalen Repositorys ist. Eine Änderung in einem Repo wird als Commit bezeichnet. Bevor ein Commit am remote Repository durchgeführt wird, muss er am lokalen ausgeführt werden.

Zudem kannst du Branches erstellen, wenn du z. B. ein neues Feature implementierst. Das sind Abzweigungen von der Hauptfassung des Codes, auf denen du Commits durchführen kannst. Das Hauptprojekt liegt dabei auf dem master-Branch. Möchtest du zwei Branches zusammenführen, nennst du dies Merge.

Möchtest du deinen Branch in den master-Branch „mergen", stellst du eine Merge request. Es kann zu einem Merge-Konflikt kommen, wenn deine Änderungen nicht mit denen deiner Kollegen zusammen passen. Du musst diesen lösen, bevor der Merge durchgeführt werden kann.

Git wird über die Kommandozeile deines PCs ausgeführt. Du verwendest dafür feststehende Befehle, die immer mit dem Wort git beginnen, gefolgt von Signalwörtern (z. B. add) und gegebenenfalls Parametern (z. B. einem Dateinamen).

Die häufigsten Befehle und die Situationen, in denen du sie brauchst, lauten: