; Git Grundlagen - Tutorials - Bootstrapper - Programmierung erklärt

Git Grundlagen

Inhaltsverzeichnis


Git ist ein mächtiges Tool und darf im Arbeitsalltag eines Entwicklers eigentlich nicht fehlen. Bei Git handelt es sich um eine Versionskontrolle. Andere, weniger oft verwendete und teilweise veraltete Alternativen zu Git heißen etwa SVN oder Mercurial. Git jedoch hat sich als de facto Standard unter den Versionskontrollen herauskristallisiert.

Was ist Git, bzw. Versionskontrolle?

Zu dieser speziellen Frage habe ich bereits ein Video auf YouTube veröffentlicht. Wer lieber Videos sehen möchte, kann dies gerne tun. Alternativ erkläre ich auch gerne als Text.

Wenn du schon einmal ein Textdokument am Computer geschrieben hast, wirst du vermutlich einmal an den Punkt gekommen sein, an dem du eine ältere Version des Dokuments haben wolltest. Glücklicherweise gibt es da ja die Rückgängig-Funktion, mit der sich Fehler schnell ausbügeln lassen. Aber was, wenn das Dokument gespeichert und das Programm geschlossen wurde? Dann ist die Funktion zurückgesetzt und man kommt nicht mehr zurück. Was dann noch übrig bleibt, ist das manuelle Bearbeiten des Textes, bis man wieder da ist, wo man sein wollte.

Genau hier setzt Git ein. Git ist also sozusagen der Rückgängig-Knopf, nachdem die Datei gespeichert wurde. Es speichert also bei jeder Änderung (Commit) die alte Version ab, und legt sie bereit, falls du sie einmal brauchst. Damit kannst du ganz einfach zu alten Versionen zurückspringen. Egal, ob das nun drei Stunden oder drei Jahre her ist. Mit Git geht nichts verloren.

Das ist beim Programmieren schon ziemlich praktisch. Oft kommt es vor, dass man mal einen Bug einbaut, den man zu Anfang gar nicht bemerkt. Wenn man dann später die Möglichkeit hat, in der Zeit zurück zu gehen, kann man genau sehen, wo der Bug eigentlich hergekommen ist.

Aber das ist nur eines der tollen Vorteile von Git. Denn auch das Zusammenarbeiten, oder vielmehr das Parallelarbeiten, wird dadurch sehr einfach gemacht. Stell dir vor, du arbeitest bei deinem Programm an einem tollen, neuen Feature. Jetzt kommt aber plötzlich der Chef rein und will, dass du einen dringenden Fehler behebst. Das Feature ist aber noch nicht fertig und wenn du es jetzt veröffentlichen würdest, würde dein Programm kaputt gehen. Das ist ein Problem, bei dem Git helfen kann. Mit sogenannten Abzweigungen (Branches) kann man für jedes Änderungspaket, also etwa das Feature und den Bugfix, eine eigene "Version" erstellen. Diese sind aber völlig unabhängig voneinander. Das Feautre, das gerade in Arbeit ist, stört den Bugfix also nicht, weil man zwischen den beiden Versionen ganz einfach hin- und herspringen kann. Wenn dann am Ende beides fertig ist, der Bugfix und das Feature, sorgt Git sogar dafür, dass beide Versionen fehlerfrei zusammengeführt werden.

Wie das geht, gucken wir uns gleich an. Aber eine Sache noch:

Was ist der Unterschied zwischen Git, GitHub und GitLab?

Oft wird Git mit GitHub verwechselt. Es ist allerdings wichtig zu verstehen, dass das beides nicht dasselbe ist. Git ist für all das, was oben beschrieben wurde, verantwortlich. Es ist die Versionskontrolle, die man sich auf seinen Computer installiert. GitHub, so wie GitLab, Bitbucket u.ä., sind Dienstleistungen, die das Git-System verwenden. Es sind also sozusagen Aufsätze auf Git, die die Arbeit mit Git erleichtern. Sie helfen etwa dabei, Projekte (oder, wie man sie im Git-Bereich nennt: Repositories) unter mehreren Entwicklern zu organisieren und Branches (Abzweigungen), sowie Commits (Änderungen) zu verwalten.

Git kann man aber ganz ohne GitHub oder GitLab verwenden. Erst einmal passiert alles lokal. Lediglich, wenn man möchte, kann man Git sagen, dass es alles, was bisher in dem Repository (Projekt) passiert ist, auf den Server von etwa GitHub hochladen soll. Dann kopiert Git das ganze Repository einfach auf den Server, beziehungsweise holt sich Änderungen vom GitHub-Server ab.

Los geht's! Vier Schritte zum Erfolg

So, nun aber zum Praktischen. Damit du erfolgreich Git verwenden kannst, musst du die folgenden Schritte durchführen:

1. Git installieren

2. A) Ein Repository erstellen

Repositories sind Projekte. Jede Anwendung und jedes Programm wären daher ein eigenes Repository. Erstmal ist ein Repository nichts weiter als ein Ordner, der all deine Projektdateien enthält, also den Quellcode zu deinem Programm.

Wechsle im Terminal/Git BASH mit cd [mein-ordner-pfad] in den Ordner, in dem all deine Projektdaten sind. Das kann natürlich auch ein leerer Ordner sein, wenn du gerade anfängst und noch nichts da ist.

Anschließend musst du git init eingeben. Damit wird ein neues Repository initialisiert. Solltest du kein Repository erstellen wollen, sondern ein bestehendes Repository verwenden wollen (etwa das deines Arbeitskollegen), musst du dies nicht tun. Mache stattdessen mit 2. B) weiter.

2. B) Ein bestehendes Repository auschecken

Wenn du schon ein Repository hast, wie etwa ein Projekt bei GitHub oder GitLab, musst du kein neues Repository erstellen. Stattdessen musst du das bestehende auschecken. Dabei ist es wichtig, dass du es in einen neuen, leeren Ordner auscheckst, weil sonst alles überschrieben würde. Es wird nämlich das gesamte Repository vom Server auf deinen Computer kopiert.

Das kannst du tun, indem du im Terminal/Git BASH mit cd [mein-ordner-pfad] in das Verzeichnis wechselst, in dem du den Projektordner anlegen möchtest. Jetzt kannst du mit git clone [pfad-zum-repository] [ordnername] das Repository auschecken. [pfad-zum-repository] ist vermutlich eine URL. Diese findest du auf GitHub, GitLab oder beim Arbeitskollegen. [ordnername]` kannst du frei wählen. Dieser Ordner wird dann angelegt und wird dein Projekt enthalten.

Ein Beispiel: Wenn du mein Einkaufslistenprojekt aus der YouTube-Serie auschecken möchtest, musst du erst die Projektseite im GitLab aufrufen. Das wäre hier. Dort findest du oben rechts einen Button Namens "Clone". Unter "Clone with HTTPS" findest du die folgende URL:

https://gitlab.com/bootstrapper/einkaufsliste.git

Das ist der Pfad zum Repository. Wenn du das nun in den Ordner "einkaufsliste" auschecken möchtest, musst du folgenden Befehl ausführen:

git clone https://gitlab.com/bootstrapper/einkaufsliste.git einkaufsliste

Damit ist dein Repository erfolgreich ausgecheckt! Du kannst jetzt ganz normal in dem Ordner arbeiten, so, wie du es normalerweise auch tun würdest.

3. Änderungen speichern

Wenn du Änderungen hast, die du speichern möchtest, musst du Git nun mitteilen, dass du den aktuellen Stand festschreiben willst. Danach wird der aktuelle Stand für immer gespeichert und du kannst jederzeit dahin zurückkehren. Das tust du, indem du alle Dateien, die du geändert hast, zu einem Commit hinzufügst. Ein Commit ist eine Art Arbeitspaket. Er enthält also eine oder mehrere Dateien mit einer oder mehreren Änderungen. Diese sollten logisch zusammengehören, damit man nachvollziehen kann, was in einem Commit gemacht wurde.

git add [dateiname] oder git add -A, um alle Änderungen hinzuzufügen. Wenn du sehen möchtest, welche Änderungen noch nicht hinzugefügt wurden, kannst du git status ausführen und dir einen Status zu jeder Datei anzeigen lassen.

Um dein Arbeitspaket nun zu verschließen und zu versiegeln, kannst du, wenn du zufrieden bist, einen Commit ausführen:

git commit -m '[mein Kommentar]'

[mein Kommentar] sollte im besten Fall alle Änderungen, die du durchgeführt hast, beschreiben. Dieser ist hilfreich, wenn man sich den Verlauf der Commits anguckt. Dann kann man immer nachvollziehen, was wann passiert ist. Hier siehst du ein Beispiel.

Sobald du diesen letzten Befehl ausgeführt hast, sind deine Änderungen gespeichert und tauchen in der Historie auf. Diese kannst du übrigens jederzeit mit git log abrufen. (Mit "q" kannst du den Modus wieder verlassen.)

4. Commits pushen und pullen

Wenn du für dich alleine arbeitest, kannst du an dieser Stelle aufhören. Wenn du aber mit anderen zusammenarbeitest oder einen Service wie GitHub oder GitLab verwendest, müssen deine mühsam erstellen Commits nun noch übermittelt werden. Momentan liegen sie nur lokal auf deinem Computer. Das ist natürlich nicht schlimm und in einigen Fällen vollkommen in Ordnung, aber oft möchte man seine Arbeit natürlich auch teilen oder sichern, falls der Computer kaputt geht.

Um die Commits nun an den Server zu übermitteln, kannst du ganz einfach git push ausführen. (Eventuell musst du beim ersten Mal ein git push origin master durchführen. Was es damit auf sich hat, erfährst du etwas weiter unten.) Damit werden nun alle Änderungen über die beim Anlegen des Repositories angegebene URL an den Server geschickt und gespeichert.

Damit du die Änderungen deiner Kollegen mitbekommst, ist es natürlich auch wichtig, dass du diese vom Server abholst. Am Ende verpasst du noch wichtige Commits! Das ist aber auch ganz schnell gemacht. Ein git pull erledigt das für dich.

Der Workflow - Zusammengefasst

Zugegeben, das war für den Anfang vielleicht etwas kompliziert. Aber keine Sorge, du wirst es bald verinnerlicht haben. Nochmal zum mitschreiben:

  1. Git installieren (das musst du natürlich nur einmal machen)
  2. Repository erstellen (git init) oder auschecken (git clone)
  3. Änderungen hinzufügen (git add) und Commits erstellen (git commit)
  4. Änderungen hochladen (git push) und wieder herunterladen (git pull)

Extras: Branches

Ich habe es eingangs schon erwähnt: Git ist auch dann praktisch, wenn mehrere Leute zusammen an einem Projekt arbeiten, oder man zeitgleich unterschiedliche Änderungen vornehmen muss. Klassisch ist das immer Schwerstarbeit: Man muss sich koordinieren und immer absprechen, wer gerade welche Datei bearbeitet, da sonst der eine dem anderen die Arbeit überschreibt. Außerdem muss man wild Dateien hin und her kopieren, um immer auf dem neusten Stand zu bleiben. Ätzend und fehleranfällig.

Git hat sich dafür das Branch-System ausgedacht. Für jede Aufgabe erstellt man sich so einen neuen Branch (git checkout -b [branch-name]). Diesen nennt man meist so, wie die Aufgabe selbst, damit man genau weiß, worum es sich handelt. Wenn ich also zum Beispiel an einem Bugfix für die Suche arbeite würde ich eventuell git checkout -b bugfix/search eingeben.

Mit diesem Befehl erstellt Git internt quasi eine Kopie aller Dateien. Du bekommst davon nichts mit. Wenn du jetzt aber anfängst, an deiner Aufgabe zu arbeiten und einen Commit durchführst, wird dieser diesem Branch zugeordnet. Wenn du jetzt wieder in den Hauptbranch (Standardmäßig heißt dieser "master") wechselst, indem du git checkout master ausführst, werden alle Änderungen, die du auf dem neuen Branch gemacht hast, von magischer Hand verschwinden und du bist wieder auf dem Stand, auf dem du vorher warst. Mit git checkout [branch-name] kommst du im Handumdrehen wieder zurück und hast keine Zeile verloren.

Dieser Trick lässt sich natürlich beliebig oft anwenden. Du kannst von "master" Branches erstellen und auch von Branches selbst. Auf GitHub etwa sieht man dann schön, von welchem Branch ein neuer Branch erstellt wurde, und welcher wohin zurückgeführt wurde.

Wenn nun eine Aufgabe fertig ist, sollte diese natürlich wieder zurück in "master" gespeichert werden, da "master" meist der Branch ist, der auf den Produktivsystemen ausgeführt wird. Auch hier unterstützt uns Git. All das nervige hin und her kopieren und das Austauschen von Zeilen in einzelnen Dateien übernimmt Git für uns. Angenommen du hast den Bugfix im "bugfix/search"-Branch erfolgreich implementiert. Jetzt würdest du diesen mit einem Commit speichern und mit git checkout master auf den Hauptbranch zurückkehren. Wenn du jetzt deine Dateien prüfst, wird die Änderung verschwunden sein. Nun empfiehlt es sich, mit git pull die letzten Änderungen vom Server zu holen. Vielleicht hat in der Zwischenzeit ein Kollege eine Änderung vorgenommen. Anschließend kannst du durch git merge bugfix/search deinen Bugfix-Branch in den master-Branch einfügen. Git knödelt jetzt alle Änderungen zusammen. Und voilà, der Bugfix ist auf master. Jetzt nur noch ein git push um die Änderungen hochzuladen und schon ist alles perfekt.

Übrigens: GitHub und GitLab unterstützen dich bei diesem Prozess besonders. Wenn du einen Branch pushst, wird dir auf der Projektseite in GitHub oder GitLab angezeigt, was passiert ist. Mit einem Merge Request (oder Pull Request - ist dasselbe, nur ein blöd gewählter Name) kann man sich dann nochmal auf der Website alle Änderungen anschauen und sie anschließend per Knopfdruck in master (oder einen anderen Branch) mergen.