Inhaltsverzeichnis

1. Der Head-Pointer

Wenn wir auf den ersten Commit zurückgehen, bewegt sich der Head-Pointer auch mit auf diesen Commit. Wir arbeiten dann also mit diesem.

Wichtig: Man kann nicht nur auf Commits zeigen, sondern auch auf Branches, wie wir hier sehen.

Der Head-Pointer zeigt auf den Main-Branch. Fügen wir an dieser Stelle einen Commit hinzu, bewegt sich der Main-Branch nach vorne. Wie das aussieht, werde ich dir gleich noch grafisch zeigen. Der Head-Pointer fährt also mit dem Main-Branch mit.

2. Der Befehl git checkout

Wir selektieren also diesen Wert, machen einen Rechtsklick und klicken dann auf „copy“. Anschließend schreiben wir „git checkout“ und fügen dahinter mit einem Rechtsklick und „paste“ den Hash-Wert ein. Drücken wir jetzt auf Enter, dann bewegen wir den Head-Pointer auf genau diesen Commit.

3. Die Warnung: "You are in detached HEAD state"

Jetzt ist erst mal etwas Beunruhigendes passiert: Wir haben die Warnung „You are in detached HEAD state“ erhalten. Was im ersten Moment dramatisch klingt, ist letztendlich aber nichts, worüber wir uns große Sorgen machen müssen. Wir befinden uns immer dann im „detached HEAD state“, wenn wir mit unserem Head-Pointer nicht auf einen Branch zeigen, sondern auf einen einzelnen Commit.

Was es damit auf sich hat, werde ich dir in der folgenden Grafik zeigen. Du hast eben bereits gelernt, dass der Head-Pointer wie ein Zeiger funktioniert, der immer auf den aktuell ausgewählten Branch oder Commit zeigt. Im Beispiel ist genau das zu erkennen.

Wir haben einen Main Branch, wobei es sich um ein kleines Projekt handelt und darüber hinaus bereits drei Commits. Das sind Commit A, B und C. Jetzt können wir zu diesem Branch noch einen weiteren Commit hinzufügen. Wenn der Head-Pointer auch auf den Branch Main zeigt, passiert dann Folgendes:

Der neue Commit wird erstellt und der Branch, auf den wir gerade zeigen, bewegt sich ein Stück nach vorne. Somit liegt der neue Commit hinter dem Branch.

4. Einen neuen Branch erstellen

Wir können natürlich auch noch einen weiteren Branch erstellen, in welchem wir ein neues Feature entwickeln. Durch die Entwicklung in einem eigenen Branch stellen wir sicher, dass der Prozess keine Auswirkungen auf unseren Main Branch hat.

Anschließend können wir auch dort wieder einen Commit anlegen. Weil der Head-Pointer bereits auf unseren Branch Feature gezeigt hat, wurde der Commit zu diesem hinzugefügt. Das heißt: Der Commit wurde vor dem Branch Feature erstellt, welcher sich wiederum ein Stück nach vorne bewegt hat.

Wie du siehst, bewegt sich der Branch, auf den der Head-Pointer zeigt, bei jedem Commit ein Stück nach vorne. Der Commit gehört dann zu diesem Entwicklungszweig (Branch).

Man kann mit dem Head-Pointer allerdings nicht nur auf Branches zeigen, sondern auch auf einzelne Commits. Damit haben wir zum Beispiel die Möglichkeit, auf den Commit C zu zeigen. Das lässt sich umsetzen, indem wir Git Checkout und den Hash-Wert dieses Commits aufrufen.

5. Detached HEAD state: Was passiert hier?

Wenn wir mit dem Head-Pointer nicht auf einen Branch, sondern stattdessen auf einen einzelnen Commit zeigen, befinden wir uns im detached Head State.

Wichtig: Dadurch wird die zu Beginn erwähnte Warnung hervorgerufen.

Denn: Beim Zeigen auf einen einzelnen Commit besteht noch immer die Möglichkeit, weitere Commits zu erstellen. Diese weiteren Commits sind dann „kopflos“ und damit nicht Teil eines bestimmten Branches. Würden wir also auf dem Commit C einen weiteren Commit setzen, sähe das Ganze folgendermaßen aus:

6. Warum der detached HEAD state problematisch sein kann

Dann gäbe es den neuen Commit F, welcher zu keinem Branch gehört. Das bedeutet: Wenn wir nun bei einem beliebigen anderen Branch arbeiten und wieder zurück zu Commit F möchten, wird es schwierig, diesen zu finden. Schließlich sind die Branches nicht lediglich dazu da, Entwicklungszweige zu erstellen, sondern dienen ebenso als Orientierungspunkte.

Wenn wir also Commits erstellen, die zu keinem Branch gehören, wird das Ganze etwas chaotisch. Aus diesem Grund erhalten wir den Hinweis, dass der HEAD gerade detached, also frei stehend ist, was immer dann passiert, wenn wir mit dem Head-Pointer auf einen einzelnen Commit zeigen, anstatt auf einen Branch.

So viel zum Thema Head-Pointer.

7. Den Projektstatus in der Git Bash nachvollziehen

Zurück in der Git Bash sehen wir noch immer die Nachricht, dass wir uns im Detached Head Space befinden, da wir zum ersten Commit gewechselt sind.

Wenn wir jetzt noch einmal „git log“ eingeben, sehen wir den Log bis zu dem Zeitpunkt in unserem Projekt, an dem wir uns gerade befinden.

Darin wird nur der Commit angezeigt, auf den der HEAD zeigt. Außerdem sehen wir, dass dort nicht wieder „HEAD“ mit einem Pfeil auf einen Branch-Namen steht, sondern lediglich „HEAD“. Er zeigt also nur auf den Commit.

8. Mit git checkout zurück zum Main Branch steuern

An dieser Stelle werden wir uns nun wieder zurück zum aktuellen Stand unseres Projekts bewegen, nämlich zum Main Branch. Dazu schreiben wir zunächst einmal „git checkout“. Da wir jetzt aber nicht zu einem Commit springen möchten, sondern zum Main Branch, benötigen wir keinen Hash-Wert. Stattdessen genügt der Name des Branches, zu dem wir möchten. Wir geben also „git checkout main“ ein:

Daraufhin befinden wir uns auch schon wieder an diesem Punkt. Wenn wir nun „git log“ in die Konsole eingeben, sehen wir beide Commits und darüber hinaus, dass der Head auf den Branch Main zeigt:

An dieser Stelle möchte ich dir zeigen, dass es einen Unterschied macht, wo wir uns im Projekt mit dem Head-Pointer befinden. Werfen wir einen genaueren Blick auf unseren Projektordner, sehen wir die Datei index.html. Öffnen wir diese, steht darin der Satz „Das hier ist meine eigene Website“. Wir sind gerade auf dem aktuellen Commit, also auf unserem Main Branch.

Springen wir nun allerdings nochmal zurück zu unserem ersten Commit, indem wir „git checkout“ und dessen Hash-Wert eingeben, dann befinden wir uns mit dem Head-Pointer wieder auf der ersten Version unseres Projekts. Beim erneuten Laden der Website taucht auch der Rechtschreibfehler der ersten Version wieder auf.

Der Ort, an dem wir uns befinden, macht also tatsächlich einen Unterschied.

Wie du siehst, können wir mithilfe von git checkout den Stand unseres Projekts wieder zu einer alten Version zurücksetzen lassen, zur aktuellen Version springen, in einen anderen Branch wechseln, usw.

Du hast in diesem Beitrag also gelernt, wie man den git checkout Befehl verwendet und welche Rolle der Head-Pointer dabei spielt.

Inhaltsverzeichnis

1. Das Website-Projekt vorbereiten

Beim Öffnen dieser Datei sehen wir den Satz „Das hier ist meine eigne Website“. Den Rechtschreibfehler im Wort „eigene“ habe ich bewusst eingebaut.

Den Grund hierfür wirst du später noch erfahren. In diesem Beitrag werden wir herausfinden, wie wir die Vorteile einer Versionsverwaltung wie Git für unser Projekt nutzen können. Wir möchten nun aus unserem Projektordner „Website“ ein sogenanntes Git Repository, also ein Git Projekt machen. Anschließend werden wir auch schon den ersten Commit an unserem Projekt vornehmen.

2. Was ist ein Git Commit?

Es gibt nun einen einfachen Befehl, mit welchem wir ein Repository erstellen können. Dieser lautet „git init“.

3. Der Befehl git init

Zuerst müssen wir uns mit der Git Bash in den Ordner bewegen, in dem wir git init ausführen möchten. Also in den Ordner, aus welchem wir ein Repository kreieren werden.

Wir navigieren also in den Desktopordner und von dort aus in den Websiteordner. Aktuell befinden wir uns im User Ordner. Doch wie gelangen wir jetzt in den Desktopordner? Ganz einfach, indem wir „cd Desktop“ schreiben:

Wie wir sehen, befinden wir uns nun auf dem Desktop. Um anschließend in den Websiteordner zu gelangen, geben wir „cd Website“ ein:

An dieser Stelle werden wir aus dem Websiteordner ein Git Repository machen. Wie bereits erwähnt, nutzt man dafür den Befehl git init. Damit initialisieren wir ein Git Repository in diesem Ordner. Nachdem wir den Befehl bestätigt haben, sehen wir die Meldung „initialized empty git repository“:

Jetzt prüfen wir erst mal, ob das auch tatsächlich ein Git Repository ist. Dazu schreiben wir „git status“. Mit diesem Befehl können wir den aktuellen Status des Repositorys abfragen:

Damit haben wir erfolgreich ein Repository erstellt! Dieses besitzt aktuell zwar noch keine Commits, dafür aber „untracked files“. Das sind Dateien, die wir in unserem Repository noch nicht verwalten. Auf dieses Thema kommen wir gleich noch zurück.

Falls bei dir nun stehen sollte „fatal: not a git repository“, wie auf dem folgenden Bild zu sehen, ist bei dir etwas schiefgelaufen:

Stelle also sicher, dass du tatsächlich in den Ordner gegangen bist, aus welchem du ein Repository erstellen wolltest und du dort den Befehl git init ausgeführt hast.

Wenn wir jetzt in unseren Ordner hineinschauen, sehen wir einen versteckten Ordner, der mit dem git init Befehl erstellt wurde. Dabei handelt es sich um den .git-Ordner. Diesen sehen wir nur dann, wenn wir in unserem Betriebssystem eingestellt haben, dass versteckte Ordner angezeigt werden.

Der versteckte Ordner enthält alle Informationen über unser darin angelegtes Git Repository. 

Wir werden uns mit diesem Ordner allerdings nicht großartig auseinandersetzen. Ich wollte dir lediglich zeigen, dass dieser existiert. Das ist also unser Git Repository.

Jetzt werden wir zu unserem Website-Ordner die Datei Todo-List hinzufügen. Dazu erstellen wir ein neues Textdokument und nennen dieses „Todo-List“. Das machen wir, um zu sehen, dass Git diese neue Todo-List-Datei auch erkennt, wenn wir noch einmal „status“ schreiben.

Navigieren wir nun also noch einmal in Git hinein und schreiben in unserem Projektordner ein weiteres Mal „git status“.

In der folgenden Abbildung sehen wir, dass wir bisher noch keinen Commit in unserem Git Repository erstellt haben. Dafür haben wir die beiden Dateien, die noch unter „untracked files“ gelistet sind.

Untracked files sind die Dateien, die unser Git Repository noch nicht verwaltet. Nun möchten wir diese beiden Dateien zum sogenannten „Staging Area“ hinzufügen, in welchem wir uns dann sozusagen unseren Commit zusammenbauen, also die erste Version unseres Git Repositorys.

4. Das Staging Area

Das Staging Area ist im Grunde einfach nur ein Zwischenschritt, in den wir unsere Dateien schreiben, die wir im nächsten Commit „committen“ möchten. Also aus welchen wir die nächste Version erstellen werden.

Um eine Datei zum Staging Area hinzuzufügen, schreibt man „git add“ und anschließend den Dateinamen. In unserem Beispiel können wir entweder den Dateinamen „Todo-List.txt“ oder lediglich „git add“ und einen Punkt (git add .) schreiben.

Wenn wir anschließend noch einmal „git status“ eingeben, sehen wir, dass nun alle „untracked“ Dateien in unserem Repository im Staging Area hinzugefügt sind:

Damit haben wir die beiden Dateien zu unserem Staging Area hinzugefügt. Nochmal zur Wiederholung: Das Staging Area ist ein Zwischenbereich, in den wir alle Dateien für den nächsten Commit schreiben.

Wir können uns im Staging Area unseren nächsten Commit also zusammenbauen und das ist ziemlich hilfreich. Wenn wir nämlich beispielsweise sehr viel an unserem Projekt gearbeitet haben, ohne dabei viele kleine Commits anzulegen, können wir im Staging Area trotzdem diese Änderungen Schritt für Schritt in kleine Commits aufteilen und erstellen. So sparen wir uns einen besonders großen Commit. Das ist an dieser Stelle auch ein wichtiger Tipp: 

Wenn man mit Git arbeitet, sollte man so kleine Commits wie möglich erstellen.

Die Commits sollten immer nur eine kleine logische Änderung beinhalten und nicht auf einen Schlag das ganze Projekt verändern. Wenn es dann nämlich zu Konflikten kommt, wird es ziemlich schwer, diese zu lösen.

Und dabei hilft uns das Staging Area immens. In das Staging Area können wir also mit „git add“ all die Dateien legen, die im nächsten Commit sein sollen.

5. Einen Git Commit erstellen

Die Dateien befinden sich also im Staging Area und nun möchten wir daraus einen Git Commit erstellen. Das bedeutet: Eine neue Version unseres Projekts. Wie machen wir das? Wir schreiben dazu den Befehl „git commit -m“ und darauffolgend zwischen Anführungszeichen (““) eine Commit Message. Generell ist es empfehlenswert, bei jedem Commit mit „-m“ eine Nachricht anzufügen. So weiß man immer, welche Änderung man dort vorgenommen hat.

Da es sich hierbei um unseren ersten Commit handelt, schreiben wir einfach mal die Nachricht „Erste Version von unserem Website Projekt“ dazu und bestätigen das Ganze mit Enter.

Damit haben wir unseren ersten Commit erstellt! Wenn wir jetzt „git status“ eingeben, sehen wir, dass wir uns gerade im Branch main befinden und es aktuell nichts weiter zu "committen" gibt. Das liegt daran, dass wir keine weitere Änderung an den getrackten Dateien unseres Projekts vorgenommen haben.

Übrigens können wir uns auch die Commit History unseres Projekts ansehen, indem wir „git log“ in die Kommandozeile eingeben. Wie wir auf der folgenden Abbildung sehen, existiert bisher nur der Git Commit, den wir gerade erstellt haben. Wir sehen dort einmal den Autor, also den Namen der Person, die den Commit erstellt hat. In diesem Fall ist das mein Name. Außerdem sehen wir die E-Mail-Adresse des Autors und den Zeitpunkt der Erstellung. Darunter steht die Commit-Message, die wir mit „-m“ angefügt haben. Das Anfügen solcher Messages ist also ziemlich sinnvoll.

Jetzt werden wir uns ansehen, was passiert, wenn wir eine Änderung an einer Datei vornehmen. Hierfür steuern wir noch einmal in unseren Website Ordner und öffnen die index.html-Datei mit notepad++.

Wie vorhin bereits erwähnt, hat sich ein Rechtschreibfehler auf unserer Website eingeschlichen. Diesen werden wir jetzt korrigieren.

Es handelt sich also nicht um die „eigne“ Website, sondern um die „eigene“ Website.

Anschließend speichern wir das Ganze ab und gehen zurück in unsere Git Bash. In der Git Bash schreiben wir nun noch mal „git status“.

Wie auf dem folgenden Bild zu erkennen ist, existiert eine neue Datei:

Die „bak“-Datei hat Notepad erstellt und ist für uns im Augenblick nicht relevant. Außerdem gibt es noch eine „modified“-Datei. Dabei handelt es sich um die index.html-Datei, die uns interessiert und die bearbeitet wurde.

Wir können jetzt die bearbeitete Datei wieder mit „git add“ zum Staging Area hinzufügen, indem wir „git add index.html“ schreiben. Um zu überprüfen, ob der Vorgang funktioniert hat, geben wir „git status“ ein. Wie wir auf der folgenden Abbildung erkennen können, befindet sich die Datei nun im Staging Area.

Jetzt werden wir einen Commit erstellen, da die neue Version den Rechtschreibfehler behoben haben soll. Wir schreiben also noch einmal „git commit -m“ und fügen hier die Bezeichnung „Korrektur von Rechtschreibfehler“ an.

Dann bestätigen wir das Ganze und der Commit ist damit erstellt. Wenn wir anschließend erneut „git log“ eingeben, können wir bereits zwei Commits erkennen.

Das ist zum einen der aktuelle Commit, in welchem wir die Korrektur des Rechtschreibfehlers vorgenommen haben und zum anderen ist das die alte Version, die wir als „Erste Version von unserem Website Projekt“ vermerkt haben.

Übrigens ist es auch möglich, zwischen Versionen hin und her zu wechseln. Das werde ich dir aber erst im nächsten Beitrag zeigen.

Im Prinzip können wir die Commit-History wie eine Art Zeitmaschine für unser Projekt verwenden und immer wieder zu einer alten Version zurückkehren. Ziemlich praktisch!

Inhaltsverzeichnis

1. Was wirst du in diesem Beitrag lernen?

2. Die Git Bash Kommandozeile

Wir starten mit den Grundlagen der Kommandozeile. Falls bei dir der Text noch ziemlich klein dargestellt sein sollte, kannst du diesen in der Git Bash durch Hinein- und Herauszoomen vergrößern oder verkleinern. Dafür hält man die STRG-Taste gedrückt und scrollt mit dem Mausrad.

Bevor wir nun mit dem ersten Befehl beginnen, möchte ich darauf eingehen, was auf der folgenden Abbildung zu lesen ist:

Auf dem Bild sehen wir „Sorm@JanekDesktop MINGW64 ~“. Beginnen wir mit dem grünen Text. „Sorm“ ist der Windows Benutzername. Das ist der Windows Benutzer, mit dem ich aktuell eingeloggt bin. Dann folgt das @-Zeichen und der Name meines Computersystems. Mein Computer heißt „JanekDesktop“ und ich bin eingeloggt mit dem Benutzer „Sorm“.

Danach steht „MINGW64“ auf dem Bildschirm. Dabei handelt es sich um die Kommandozeile, die wir verwenden. Also um eine MINGW64-Kommandozeile. Anschließend folgt eine Tilde (~). Die Tilde symbolisiert, dass wir uns gerade im Benutzerverzeichnis befinden. Das kann ich dir auch direkt anhand des ersten Befehls veranschaulichen. Und zwar ist das der pwd-Befehl.

3. Der pwd-Befehl

Wie du siehst, ist das mein Benutzerordner. Die Tilde ist also einfach eine Abkürzung für den Benutzerordner. Der Befehl „pwd“ steht für „print working directory“, was so viel bedeutet wie „gebe das aktuelle Arbeitsverzeichnis aus“. Und das ist das Verzeichnis, in welchem wir uns gerade befinden.

Als Nächstes möchte ich dir zeigen, wie du in verschiedene Ordner hinein navigieren kannst. Natürlich kannst du dein aktuelles Arbeitsverzeichnis auch jederzeit wechseln und genau das macht man mit dem cd-Befehl.

4. Der cd-Befehl

Wenn ich nun allerdings „cd /c/users/Sorm/Desktop“ schreibe, lande ich auf meinem Desktop, wie man in der folgenden Abbildung erkennen kann:

Auf dem Bildschirm steht bereits "Benutzerverzeichnis Desktop". Wenn ich jetzt den pwd-Befehl eingebe, sehen wir, dass ich mich gerade auf dem Desktop befinde:

Möchte ich nun in der Ordnerstruktur wieder eine Ebene nach oben gehen, also vom Desktopordner zurück in den übergeordneten Sorm-Ordner, dann schreibe ich dafür „cd“ und bestätige die Eingabe mit Enter. Dadurch bewege ich mich wieder in das übergeordnete Verzeichnis, also in den Benutzerordner:

Jetzt steuere ich mal in einen Beispielordner, den ich für diese Lektion erstellt habe. Dieser befindet sich auf meinem Desktop und darin zeige ich dir noch einen weiteren Befehl. Da er auf dem Desktop liegt und "Beispielordner" heißt, schreibe ich: „cd Desktop“.

An dieser Stelle kann ich einfach Desktop schreiben, weil ich aktuell im User Verzeichnis bin und Desktop ein Ordner ist, welcher sich im User Verzeichnis befindet. Das heißt, wenn ich das so angebe, gelange ich auch tatsächlich wieder auf meinen Desktop:

Hier auf dem Desktop gibt es nun einen Ordner namens „Beispielordner“. Wenn ich diesen noch in die Konsole eintippe und bestätige, werde ich in diesen hinein geleitet.

Jetzt möchte ich dir den sogenannten ls-Befehl vorstellen. Doch vorher müssen wir zunächst in der bereits vollen Konsole etwas Platz schaffen. Das gelingt uns, indem wir „clear“ eingeben und diese dadurch leeren:

Jetzt, wo uns wieder eine leere Konsole zur Verfügung steht, sehen wir uns den ls-Befehl an.

5. Der ls-Befehl

Mit dem ls-Befehl können wir den Inhalt des aktuellen Ordners, also des Ordners, in dem wir uns gerade befinden, ausgeben lassen. Im Moment sind wir im Desktop-Beispielordner, welcher eine Datei und einen Ordner enthält. Diese werde ich dir an dieser Stelle zeigen.

Dazu gebe ich „ls“ in die Kommandozeile ein, drücke die Enter-Taste und daraufhin wird uns der Inhalt dieses Verzeichnisses aufgelistet:

Wir sehen die verschiedenen Elemente in unterschiedlichen Farben hervorgehoben. Die Einkaufsliste.txt-Datei ist in Weiß geschrieben, wobei es sich um eine normale Datei handelt. Ein Ordner hingegen, wie der mit dem Namen „weiterer Ordner“, ist blau hervorgehoben. Das Nützliche am ls-Befehl ist also, dass wir damit immer sehen können, was sich im aktuellen Verzeichnis, in welchem wir sind, befindet.

An dieser Stelle möchte ich dir zeigen, wie du ein Element verschieben bzw. umbenennen kannst.

6. Der mv-Befehl

Um eine Datei beispielsweise zu verschieben, nutzt man den mv-Befehl, was für „move“ steht. Damit ist gemeint, ein Element in ein anderes hinein zu bewegen. Wie funktioniert das Ganze? Wir möchten beispielhaft einmal die Einkaufsliste.txt-Datei in den Ordner „weiterer Ordner“ verschieben. Wie machen wir das? Wir schreiben dazu einfach „mv“, dann das Element, das wir verschieben möchten (Einkaufsliste.txt) und anschließend geben wir das Element, also den Ordner an, in den wir es verschieben möchten. Da wir es in den Ordner „Weiterer Ordner“ verschieben möchten, geben wir diesen an:

Jetzt gibt es hier allerdings ein Problem. Wenn wir diese Zeile so bestätigen, denkt die Kommandozeile, wir möchten die Einkaufsliste.txt-Datei in einen Ordner namens „Weiterer“ verschieben. Das liegt daran, dass sich eine Leerzeile zwischen „Weiterer“ und „Ordner“ befindet. Im Namen selbst befindet sich tatsächlich auch ein Leerzeichen, allerdings muss die Kommandozeile sehen, dass der Name nach dem Leerzeichen noch weiter geht.

Um das zu ermöglichen, schreiben wir vor dem Leerzeichen ein Backslash (\):

Wenn wir diese Zeile jetzt bestätigen und anschließend den Befehl „ls“ schreiben, sehen wir, dass es funktioniert hat und sich im Beispielordner nur noch das Unterverzeichnis „Weiterer Ordner“ befindet:

Denn schließlich haben wir die Einkaufsliste.txt-Datei in den Ordner „Weiterer Ordner“ verschoben.

Um dir das Ganze zu demonstrieren, navigieren wir hierzu in „Weiterer Ordner“ und ergänzen bei der Namensangabe aufgrund des Leerzeichens wieder das Backslash. Anschließend drücken wir Enter und befinden uns daraufhin auch schon darin:

Wenn wir an dieser Stelle nun „ls“ schreiben, sehen wir, dass sich hierin nun auch die Einkaufsliste.txt-Datei befindet:

Um in der Konsole wieder etwas Platz zu schaffen, schreibe ich noch einmal „clear“ und drücke die Enter-Taste. Dann gebe ich wieder „ls“ ein und wie sich daraufhin erkennen lässt, haben wir wirklich nur die Einkaufsliste.txt-Datei im Ordner „Weiterer Ordner“.

Nun möchte ich dir zeigen, dass du die Einkaufsliste.txt-Datei auch wieder in das übergeordnete Verzeichnis schieben kannst, indem du „mv Einkaufsliste.txt . .“ schreibst:

Dass wir diese Datei in das übergeordnete Verzeichnis geschoben haben, kann ich dir noch einmal veranschaulichen, nachdem ich die Konsole nochmals mit „clear“ freigeräumt habe.

Navigieren wir nun noch mal selbst ins übergeordnete Verzeichnis, indem wir „cd . .“ eingeben. Nachdem wir den Befehl mit Enter bestätigt haben, geben wir „ls“ ein und sehen dann, dass die Einkaufsliste.txt-Datei wieder im Beispielordner ist:

Mit dem Befehl „mv“ kann man aber nicht nur Dateien verschieben, sondern diese auch umbenennen. Um Einkaufsliste.txt beispielsweise umzubenennen, schreibt man „mv Einkaufsliste.txt“ und gibt anschließend einen neuen Namen eines Elements an, das hier noch nicht existiert.

Wenn wir nun also einfach einen neuen Namen schreiben, anstatt den Namen des Ordners anzugeben, der sich im aktuellen Verzeichnis befindet, verschieben wir die Einkaufsliste nicht, sondern benennen sie um.

Beispielhaft nenne ich das Ganze „Shoppinglist.txt“ und lasse mir die Änderung mit dem Befehl „ls“ anzeigen:

Wie wir sehen, hat es funktioniert!

7. Der rm-Befehl

An dieser Stelle möchte ich dir zeigen, wie man mithilfe des „rm“-Befehls, welcher für „remove“ steht, Dateien löschen kann. Wir werden nun unsere Shoppinglist.txt-Datei löschen, indem wir „rm Shoppinglist.txt“ eingeben. Wenn wir das nun ausführen und anschließend „ls“ schreiben, sehen wir, dass die Shoppinglist.txt-Datei entfernt wurde:

Wichtig:
Mit diesem Befehl sollte man sehr vorsichtig umgehen. Die Shoppinglist.txt-Datei ist nämlich nicht im Papierkorb gelandet, sondern wurde tatsächlich entfernt.

Zum Schluss werden wir noch ein neues Verzeichnis mithilfe eines Konsolenkommandos erstellen.

8. Der mkdir-Befehl

Mit dem „mkdir“-Befehl, welcher für „make directory“ also „neues Verzeichnis erstellen“ steht, kann man einen neuen Ordner erstellen. Ich könnte an dieser Stelle zum Beispiel einen neuen Ordner namens „Listen“ anlegen, in dem ich verschiedene Einkaufslisten speichere.

Wenn ich diese Zeile im Anschluss bestätige, erstellt das Programm den neuen Ordner in unserem Beispielordnerverzeichnis, in welchem wir uns gerade befinden. 

Schreibe ich anschließend also noch „ls“, sehen wir den neuen Ordner „Listen“:

In diesen Ordner kann ich nun auch mit dem Befehl „cd“ hinein navigieren, obwohl er aktuell noch leer ist, weil wir ihn gerade erst erstellt haben:

So einfach kann man also mit „mkdir“ einen neuen Ordner erstellen.

An diesem Punkt habe ich dir auch schon die wichtigsten grundlegenden Befehle gezeigt, die du kennen solltest, um dich in der Git Bash zurechtzufinden.

Ich gebe nun noch einmal „clear“ ein, um die Konsole zu leeren und schreibe dann „cd“, um zurück ins User-Verzeichnis zu navigieren.

Wenn ich nun „pwd“ eingebe, siehst du, dass wir uns wieder im Verzeichnis /Users/Sorm befinden:

Zu guter Letzt möchte ich dir noch ein paar nützliche Tipps zeigen, wodurch du mit der Konsole schneller arbeiten kannst.

9. 3 nützliche Tipps für das Arbeiten in der Git Bash

Tipp 1: Text aus Zwischenablage einfügen

Zuerst einmal sehen wir uns an, wie du in der MINGW64 Bash einen Text aus einer Zwischenablage einfügen kannst. Wir können nun also beispielsweise den Pfad aus einem Ordner kopieren und diesen in der Konsole einfügen:

Wenn ich dafür nun STRG und V drücke, wie man das aus anderen Anwendungen gewohnt ist, stellen wir fest, dass das hier nicht funktioniert.

Um aus der Zwischenablage einen Text in der Konsole einzufügen, haben wir zwei Möglichkeiten:

1. Rechtsklick mit der Maus und „Paste“ auswählen.

2. SHIFT und die EINFG-Taste drücken.

Wie wir auf der folgenden Abbildung sehen, konnten wir den Text dadurch einfügen:

Zu wissen, dass man einen kopierten Text aus der Zwischenablage nicht mit STRG + V, sondern mit SHIFT + EINFG in der Konsole einfügt, ist also ziemlich wichtig.

Tipp 2: Letzten Befehl aufrufen und in die Konsole kopieren

Als Nächstes möchte ich dir den Befehlsverlauf zeigen. Mit der Pfeiltaste nach oben kannst du den letzten Befehl, den du geschrieben hast, noch mal direkt in die Konsole kopieren. Wenn du die Pfeiltaste weitere Male nach oben drückst, kannst du das sogar noch mit anderen Befehlen aus der Vergangenheit durchführen. Auf diese Art und Weise ist es möglich, durch vorherige Befehle, die du bereits geschrieben hast, nochmals zu navigieren und sie zu wiederholen. So sparst du dir die Zeit, sie erneut auszuschreiben.

Schreibe ich jetzt beispielsweise „pwd“, dann gibt das Programm mein aktuelles „working directory“ aus. Drücke ich nun aber noch mal die Pfeiltaste nach oben, schreibt das Programm direkt wieder „pwd“ in die Konsole. Weil das der letzte Befehl gewesen ist, den ich geschrieben habe. Wenn ich die Pfeiltaste hingegen nach unten drücke, wird der Befehl wieder entfernt.

Tipp 3: Autovervollständigung

Zu guter Letzt möchte ich dir die Autovervollständigung des Terminals vorstellen. Durch Drücken der Tab-Taste kann man den Text, den man gerade in der Konsole geschrieben hat, als Befehl autovervollständigen lassen.

Wir befinden uns gerade im Beispielordner, welcher sich auf meinem Desktop befindet. Dieser ist bei mir geöffnet und wir sehen dort rechts Ordner 1, Ordner 2 und Ordner 3:

Ich möchte nun mal in Ordner 3 navigieren. Dazu schreibe ich „cd“ für „change directory“, gefolgt von „Ord“ und drücke anschließend die Tab-Taste. Wie wir sehen, wird das Wort „Ordner“ auch direkt autovervollständigt:

Jetzt gibt es hier aber verschiedene Ordner mit unterschiedlichen Zahlen. Wenn ich nun noch 2-mal die Tab-Taste drücke, zeigt mir die Konsole die verschiedenen Optionen an:

Möchte ich beispielsweise den Ordner 2 auswählen, dann tippe ich die Zahl 2 ein und drücke anschließend die Enter-Taste:

Man kann also mit der Tab-Taste Texte autovervollständigen und genau das würde ich dir empfehlen, zur Gewohnheit zu machen. Damit kannst du nämlich wesentlich effektiver, schneller und mit mehr Spaß in der Konsole arbeiten. Denn: Man vertippt sich damit seltener.

An dieser Stelle sind wir auch schon am Ende dieses Beitrags angekommen. Du hast nun die Grundlagen des MINGW-Terminals kennengelernt und weißt, wie man sich durch das File-System navigieren kann. Im kommenden Artikel werden wir mit Git starten.

Inhaltsverzeichnis

1. Git installieren

Dann landen wir auch schon auf der Downloadseite. Du kannst Git installieren für MacOS, Windows oder Linux. Ich wähle Windows aus und daraufhin startet auch schon automatisch der Download:

Der Installer

Schritt 4:
Danach können wir den Start Menü Ordner wählen. Hier lasse ich auch alles so, wie es bereits ist und klicke wieder auf „Next“.

Schritt 5:
Jetzt müssen wir einen Texteditor für Git auswählen. Hier wird standardmäßig Vim verwendet, welcher meiner Meinung nach sehr kompliziert und nicht wirklich intuitiv ist. Ich wähle deshalb Visual Studio Code aus. Du kannst natürlich den wählen, der dir persönlich am meisten zusagt. Danach klicken wir wieder auf „Next“:

Schritt 6:
Nun müssen wir einstellen, wie Git den Hauptentwicklungszweig eines neuen Git-Projekts immer standardmäßig nennt. Früher nannte man den Hauptentwicklungszweig (default branch) immer Master Branch. Da dieser Name allerdings an die Sklavenhaltung erinnert und nicht inklusiv ist, forderten einige Stimmen eine Änderung des Namens.

Wenn du auf diesem Fenster auf „Let Git decide“ klickst, nennt das Programm den Hauptentwicklungszweig aktuell noch Master. Wie man dem Text darunter entnehmen kann, soll sich das in der Zukunft aber noch ändern.

Ich wähle hier „Override the default branch name for new repositories“ und nenne das Ganze „Main Branch“. Auch viele Entwicklerteams in zahlreichen Unternehmen haben das bereits so umgestellt und nennen ihre Hauptentwicklungszweige nicht mehr "Master" Branch, sondern "Main" Branch.

Ich persönlich finde auch, dass das etwas besser und aussagekräftiger klingt. Du kannst ihn natürlich auch anders nennen oder „Let Git decide“ auswählen. Nun klicke ich wieder auf „Next“:

Schritt 7:
Jetzt müssen wir einstellen, wie wir Git von unserer Kommandozeile aus verwenden möchten. Wir können oben also beispielsweise auswählen, dass wir Git nur von der „Git Bash“ aus benutzen wollen, die wir mit dem Installer zusammen mit Git installieren.

Oder wir wählen die empfohlene Option aus, die ermöglicht, dass wir Git von der Kommandozeile und von 3rd-party Software aus verwenden können. Dadurch wird eine minimale Änderung an unserer Path-Variable in Windows vorgenommen.

Darüber hinaus können wir auswählen, dass wir Git und optionale Unix-Tools von unserem Command Prompt verwenden möchten. Damit wird unsere Path-Variable so bearbeitet, dass es Git und optionale Unix-Tools hinzufügt.

Wir wählen nun aber einfach die empfohlene Option „Git from the command line and also from 3rd-part software“. In dieser Git-Tutorialreihe verwenden wir auch lediglich die Git Bash, die das Programm mitinstalliert. Dann klicken wir wieder auf „Next“:

Schritt 8:
An dieser Stelle müssen wir unseren SSH-client wählen, den Git verwendet. Wir wählen hier einfach die Standardeinstellung „Use bundled OpenSSH“. Diese liefert uns das Programm nämlich mit der Installation mit. Wenn du aber PuTTY für SSH-Aufgaben verwenden möchtest, dann wähle an dieser Stelle einfach die zweite Option.

Es gibt allerdings noch die dritte Option: „Use external OpenSSH“. Bei dieser Option verwendet man einen External OpenSSH-Client. Diesen liefert das Programm aber nicht mit dieser Installation mit. Stattdessen sucht es das Ganze auf der Path-Variable.

Wir wählen nun aber „Use bundled OpenSSH“ und klicken auf „Next“:

Schritt 9:
Auf dem nächsten Fenster müssen wir das HTTPS Transport backend auswählen. Wir wählen die Standardeinstellung „Open SSL“. Möglich wäre es auch, die native Windows Secure Channel Library zu nutzen. Wir setzen das Ganze aber mit „Open SSL“ fort und klicken auf „Next“.

Schritt 10:
Hier müssen wir nun auswählen, wie Git mit Line Endings, also dem Ende einer Zeile in Textdateien umgehen soll. Wenn wir auf der Tastatur die Enter-Taste drücken, legt eine Textdatei einen unsichtbaren Character an, der ein Zeilenende repräsentieren soll.

Verschiedene Betriebssysteme handhaben nun solche Zeilenenden unterschiedlich. Aus diesem Grund kann man hier einstellen, wie Git mit den Zeilenenden umgehen soll. Wir wählen nun die Standardeinstellung „Checkout Windows-style, commit Unix-style line endings“ aus. Anschließend drücken wir wieder auf den „Next“-Button:

Schritt 11:
Jetzt müssen wir auswählen, welchen Terminal Emulator die Git Bash verwenden soll. Uns stehen zwei Optionen zur Auswahl. Zum einen die Standardeinstellung „Use MinTTY“ und zum anderen „Use Windows‘ default console window“.

Weil MinTTY mehr Features besitzt und die Arbeit sich damit besser gestaltet, wählen wir dieses. Im unten stehenden Text sind die Unterschiede dazu noch aufgelistet. Ich werde darauf allerdings nicht eingehen, da das den Rahmen dieses Artikels sprengen würde. Wir wählen hier also einfach „Use MinTTY“ und klicken auf „Next“:

Schritt 12:
Als Nächstes müssen wir das Standardverhalten des Befehles „git pull“ einstellen. Dabei stehen uns wieder drei Optionen zur Auswahl. An dieser Stelle weißt du vermutlich noch gar nicht, welcher Befehl „git Pull“ ist und was man damit macht. Ich erkläre es dir mal ganz einfach:

Stell dir vor, du hast einen Remote Repository, also einen Git-Repository, der sich nicht auf deiner lokalen Maschine befindet und du möchtest die Daten von diesem Repository herunterladen. Wenn du jetzt dein eigenes lokales Repository, dein eigenes lokales Git-Projekt mit diesen heruntergeladenen Daten aktualisieren möchtest, machst du einen git pull.

Wir wählen an dieser Stelle „Default“ aus. Dabei handelt es sich um das Standardverhalten dieses Befehls. Anschließend klicken wir wieder auf „Next“:

Schritt 13:
Jetzt müssen wir den Credential Helper einstellen. Wir wählen wieder die Standardeinstellung, nämlich den „Git Credential Manager“ und klicken auf „Next“.

Schritt 14:
Auf dem nachfolgenden Fenster können wir nun noch ein paar zusätzliche Funktionen einstellen. Wir lassen den Haken bei „Enable file system caching“ gesetzt. Damit aktiviert das Programm file system caching, welches dafür sorgt, dass manche Operationen schneller sind. Das wird auch im Text darunter beschrieben.

„Enable symbolic links“ kann man auch auswählen. Das werde ich allerdings nicht tun, da wir diese Option aktuell nicht benötigen. Man kann damit symbolische Links verwenden. Das ist im Grunde so etwas wie eine Verknüpfung zu einer Datei. Im Anschluss klicken wir wieder auf „Next“.

Schritt 15:
Jetzt können wir noch weitere experimentelle Features aktivieren oder deaktiviert lassen. Ich lasse solche experimentellen Features generell immer deaktiviert. Abschließend klicken wir auf „Install“, wodurch wir schließlich Git installieren:

2. Git einrichten

Wenn wir die Git Installation nun abgeschlossen und zu Beginn im Installer den Desktop Shortcut ausgewählt haben, sehen wir nun auf unserem Desktop die Verknüpfung zu unserer Git-Bash.

Wenn wir diese doppelt klicken, öffnet sich ein Terminal, das wir uns nun einmal genauer ansehen werden. Dafür stellen wir zunächst den Vollbildmodus ein.

Den Text können wir vergrößern, indem wir die Strg-Taste gedrückt halten und das Mausrad scrollen:

Zum Abschluss möchten wir noch unseren Nutzernamen und unsere E-Mail konfigurieren. Der Benutzername und unsere E-Mail sind immer bei unseren Commits vermerkt.

Sprich: Wenn wir einen Commit machen, also eine Änderung an unserem Projekt vornehmen, ist diese durch unseren Namen und unsere E-Mail-Adresse gekennzeichnet.

Weil wir Commits im Nachhinein nicht mehr ändern können, tragen wir die Informationen direkt am Anfang richtig ein.

Um unseren Benutzernamen zu verändern, schreiben wir „git config --global user.name“. In Anführungszeichen schreiben wir dann den Namen. In meinem Fall ist das „Janek Pruin“:

Den Namen können wir uns jetzt auch einfach mal ausgeben lassen, indem wir schreiben: „git config --global user.name“:

Wie wir auf der Abbildung erkennen, steht darunter nun der richtige Benutzername.

Jetzt werden wir noch die E-Mail einstellen. Dazu schreiben wir „git config --global user.email  "beispiel@programmierenstarten.de“. Du kannst an dieser Stelle natürlich deine eigene E-Mail-Adresse eingeben. Anschließend bestätige ich das Ganze mit Enter und lasse mir diese auch noch mal mit der Zeile „git config --global user.email“ ausgeben:

Damit haben wir auch schon Benutzername und E-Mail eingestellt!

Da wir nun erfolgreich Git installieren konnten, werden wir uns im nächsten Beitrag zur Git-Tutorialreihe die Git-Bash noch genauer ansehen. Du wirst dort lernen, wie man darin richtig navigiert und mit der Konsole arbeitet. Denn diese Konsolen sind gerade für Neueinsteiger, die zuvor mit einer Bash noch nie gearbeitet haben, meist etwas verwirrend.

Ich werde dir also die Grundlagen der Git-Bash beibringen, damit du dich gut zurechtfinden und damit arbeiten kannst. Anschließend werden wir noch tiefer in die Materie eintauchen.

Inhaltsverzeichnis

1. Was ist Git?

2. Vorteil #1: Versionen

Mit Git hat man Versionen seiner Projekte. Git ist, wie bereits erwähnt, eine Versionsverwaltung. Das bedeutet, du kannst dir Git wie eine Zeitmaschine vorstellen. Sollte seit dem letzten hinzugefügten Update oder Feature etwas kaputt gegangen sein, kann man mit Git nämlich jederzeit zu einem früheren Stand eines Projekts zurückspringen und diesen wiederherstellen.

Wenn sich in unser Projekt also Fehler einschleichen, können wir diese wieder rückgängig machen.

Und das ist unheimlich wertvoll! Stell dir beispielsweise einmal das folgende Szenario vor:

Wir arbeiten an einem Grafikeditor wie Photoshop oder paint.NET und uns kommt die Idee für ein großartiges neues Feature in den Sinn, mit welchem man Effekte zu Bildern hinzufügen kann. Diese Idee setzen wir auch direkt in die Praxis um und veranlassen ein Update für unser Programm.

Komischerweise bekommen wir seit dieses neue Feature veröffentlicht ist plötzlich ständig E-Mails von Kunden, die Programmabstürze und andere Probleme beklagen.

Wir stellen also fest, dass unsere Software durch das letzte Effekte-Feature nicht mehr richtig funktioniert – irgendetwas ist schiefgelaufen.

Mithilfe von Git ist es jetzt möglich, einfach zu dem Punkt zurückzuspringen, an dem wir das Feature noch nicht implementiert hatten. Wir müssen also nicht unter Druck nach einer Lösung für das Problem aufgrund des neuen Features suchen, sondern können mit ein paar einfachen Befehlen wieder zu unserer vorherigen Version zurückkehren. So können wir das Ganze wieder sauber und strukturiert aufs Neue entwickeln und dafür sorgen, dass es diesmal fehlerfrei funktioniert.

Wir können durch Git also für jedes neue Feature, das wir implementiert haben, eine neue Version für unser Projekt erstellen. Das setzen wir mithilfe von sogenannten Commits um.

3. Was ist ein Commit?

Nun können wir im Verlauf dieses Zeitstrahls weitere Commits (Änderungen) zu unserem Projekt hinzufügen. Ein neuer Commit könnte beispielsweise sein, dass wir eine Benutzeroberfläche gestaltet haben:

Ein weiterer Commit könnte so aussehen: Wir haben ein Zeichnen-Feature zu unserer Software hinzugefügt. Man kann jetzt also in unserem Grafikeditor auch mit einem Pinsel malen.

Anschließend fügen wir zwei weitere Commits hinzu: eine Speicher- und eine Ladefunktion.

Und zu guter Letzt fügen wir noch das Effekte-Feature für unsere Grafiksoftware hinzu:

Genau an dieser Stelle mussten wir feststellen, dass im Programm etwas kaputt gegangen ist. Denn seit wir diesen Commit hinzugefügt haben, erhalten wir zahlreiche E-Mails, die uns darauf hinweisen, dass das Programm nicht mehr so funktioniert, wie es sollte.

Mithilfe von Git können wir jetzt also ganz einfach zu dem Punkt zurückkehren, an dem es zuletzt noch funktioniert hat und von dort aus weiterentwickeln.

An diesem Punkt behalten wir also noch alle Fortschritte der vorherigen Commits, das letzte Effekt-Feature ist nun aber nicht mehr enthalten.

Versionen sind allerdings nicht der einzige Vorteil, den Git zu bieten hat.

4. Vorteil #2: Branches

Jetzt haben wir eine Idee für ein neues Feature. Wirklich sicher sind wir uns allerdings noch nicht, ob dieses tatsächlich in unser Projekt passt. Genau deshalb möchten wir das Feature erst einmal unabhängig von diesem Hauptzweig entwickeln.

Wir können also einfach einen neuen parallelen Branch erstellen, der den Hauptentwicklungszweig nicht beeinflusst. Auf diesem Branch können wir unser neues Feature entwickeln.

Wenn wir das Feature dann irgendwann fertig entwickelt haben und es in unser Projekt passt, können wir den Nebenentwicklungszweig, auf dem wir nur das Feature entwickelt haben, mit unserem Hauptentwicklungszweig „mergen“. Sie also zusammenfließen lassen.

Dass wir auf diese Weise neue Features experimentell entwickeln können, ohne unser Hauptprojekt zu beeinflussen, ist ein weiterer großer Vorteil von Git.

5. Vorteil #3: Einfaches Zusammenarbeiten

Bei Projekten mit mehreren Entwicklern kann es bekanntermaßen hin und wieder zu Dateikonflikten kommen, wenn zwei Entwickler beispielsweise eine Codedatei bearbeiten. Oder sie möchten ihre Commits erstellen und die Änderungen stehen unbeabsichtigt in Konflikt miteinander.

Git erkennt solche Konflikte und hilft den Entwicklern dabei, diese relativ einfach zu lösen. Das ist gerade für die Teamarbeit ein weiterer enormer Vorteil.

Bei den drei Vorteilen, die du in diesem Beitrag kennengelernt hast, handelt es sich um die Hauptvorteile von Git. Damit stellt es ein unglaublich wertvolles Werkzeug dar. Es ist kostenlos und einfach in der Handhabung, sobald man es einmal gelernt hat. Und genau das wirst du auch in den weiteren Beiträgen zu diesem Thema.

Ich kann wärmstens empfehlen, Git für die eigenen Projekte zu nutzen.

6. Was ist GitHub?

Jetzt steht aber noch eine andere Frage im Raum: Wenn Git die Versionsverwaltung ist, was ist dann eigentlich GitHub?

Diesen Namen liest man auch nicht selten im Internet. Viele, die diesen Beitrag lesen, wissen sicherlich auch bereits, dass GitHub eine Website ist.

GitHub ist eine Online-Plattform, die auf github.com zu erreichen ist. Auf github.com kann man sich einen Account erstellen und darauf eigene Git-Projekte hosten oder sich ganz einfach an deren Open Source Projekten beteiligen. GitHub ist die größte Plattform für Programmierprojekte der Welt und diese nutzt eben Git.

Du weißt jetzt also, dass Git selbst die Software ist, die die Versionsverwaltung darstellt und dass es sich bei GitHub um eine Plattform handelt, auf der Entwickler Git-Projekte hosten können.

Auf GitHub werde ich noch in einem zukünftigen Beitrag eingehen.