Joopi - Doku Git und GitHub

Die Nutzung von Git und GitHub kann in Projekten von Vorteil sein. Hier dokumentiere ich, wie Git zu nutzen ist. Die Nutzung von GitHub ist sekundär, denn dieses benötige ich nur, sollte ich meine Projekte im Internet öffentlich machen wollen.

Ich nutze zum Üben die Lehrgangsreihe von The Net Ninja.

Meine eigenen Vorbemerkungen:

Es macht im Grunde genommen Sinn, dass die Projekte, an denen gearbeitet wird, zentral auf dem lokalen Rechner abgelegt werden. Somit ist auch nur ein Oberprojektordner notwendig. Dieser Oberprojektordner wird dann wiederum mit weiteren Ordnern je Einzelprojekt bestückt. Diese Ordner werden, sofern sie von Git zu nutzen sind, später durch die Initialisierung zu Repositories. Um nämlich Git in Gänze richtig zu nutzen, müssen Git-Repositories angelegt sein.

Das bedeutet, dass in dem Projektordner ein versteckter Ordner .git angelegt wird, in dem dann alle Veränderungen nachgehalten, also getrackt, werden.

Nachdem Git installiert wurde

Code:
git config --globel user.name Tuennes

Code:
git config --globel user.email tuennes@yahoo.de

Damit ist Git personalisiert.

Um festzustellen, welcher User für Git angelegt werde, ist folgender Befehl auf der Konsole abzusetzen.

Code:
git config user.name

Projekt initialisieren

Code:
git init

Mit diesem Befehl wird das Repository initiiert. Innerhalb des Ordner bzw. des Repositories können weitere Ordner erstellt werden. Auf der Konsole kann direkt mit dem Befehl ```touch``` eine leere Textdatei erzeugt werden, z.B. index.html.

Welche Dateien sind im Repo

Code:
git status

Dieser Befehl zeigt alle im Repo vorhandenen Dateien und deren aktuellen Status.

Ein Status ist z.B. untracked. Das bedeutet, die Datei ist da, aber noch nicht in der Staging-Area enthalten.

Dateien, die noch nicht in der Staging-Area sind, werden in der Farbe Rot dargestellt. Dateien, die bereits hinzugefügt wurden, werden in der Farbe Grün angezeigt.

Die textliche Beschreibung ist aber auch ausreichend, um zu erkennen, welche Dateien hinzuzufügen sind. Das muss nicht einzeln geschehen.

Datei in Staging-Area hinzufügen

Code:
git add index.html

Um eine Datei in die Staging-Area hinzuzufügen, bedarf es nur dem vorgenannten Befehl.

Datei aus Staging-Area löschen

Code:
git rm --cached index.html

Sofern eine Datei im Repo nicht mehr benötigt wird, kann sie mit dem vorgenannten Befehl aus der Staging-Area herausgelöscht werden. Das bedeutet nicht, dass die Datei physisch gelöscht wurde. Sie ist nur nicht mehr im Repo.

Alle Dateien hinzufügen

Code:
git add .

In einem großen Projekt wäre es sehr aufwendig, wenn jede einzelne Datei, die erstellt wurde, dem Repo hinzuzufügen wäre. Mit dem vorgenannten Befehl werden alle neuen Dateien, die noch nicht im Repo sind, hinzugefügt.

Wichtig ist, dass zu bestehenden Dateien, die geändert wurden, entsprechende Mitteilungen über den Grund der Änderung, vermerkt werden. Das ist das Kommittment, welches sehr wichtig ist.

Ein Kommitment absetzen

Code:
git commit -m "added index and styles files"

Dieser Befehl ist relativ global und bezieht sich nicht auf einzelne Dateien, sondern auf die Dateien, die neu sind bzw. geändert wurden.

Die Option **-m** bedeutet, dass eine Mail erzeugt und an die Projektteilnehmer gesendet wird.

Der notwendige und wichtige Kommentar zum Kommitment wird hinter der Option in Hochkommata gesetzt und sollte die Situation erklären.

Mit diesem Kommitment wird eine eindeutige ID erzeugt, die im Repo abgespeichert wird.

Es wird eine Info ausgegeben, die u.a. enthält, wieviele Zeilen insgesamt hinzugefügt (vielleicht auch gelöscht) wurden. Werden zum Projektbeginn mehrere Dateien mit einem Kommitment belegt, so sind alle vorhandenen Zeilen in Summe dann in der Info zu sehen.

Logfiles der Kommitments ansehen

Code:
git log

Sobald z.B. bestehende Dateien verändert werden, müssen diese irgendwann wieder der Staging-Area mitgeteilt werden. Das geht über den "add"-Befehl und es wird angezeigt, welche Dateien geändert (modifiziert) wurden.

Sobald das passiert ist, sollte wieder ein Kommitment erfolgen, welches wieder geloggt wird.

Mit dem obigen Befehl, können alle abgesetzten Kommitments betrachtet werden. Allerdings werden hierbei alle Einträge im Logfile, also in der Historie, angezeigt. Das kann sehr unübersichtlich sein, wenn das Projekt groß ist.

Code:
git log --oneline

Um nicht erschlagen zu werden, wird bei der Ausführung des obigen Befehls je Kommitment nur eine Zeile ausgegeben, die eine Zusammenfassung der Veränderungen beinhaltet.

Das einfache Hinzufügen und Betrachten der Dateien bzw. der Einträge in der Log-Datei ist nicht alles, denn es werden oftmals auch Fehler gemacht, die wieder zu beheben sind.

Hier sind zum Kommitment 3 Befehle vorhanden:

Checkout commit
Revert commit
Reset commit

Ein Kommitment zurücknehmen

Code:
git checkout af6b84c

Sofern etwas falsch war oder zu verändern ist, kann ein Kommitment wieder zurückgenommen werden. Dazu ist über die Loghistorie die entsprechende ID zu erkunden und kann dann mit dem obigen Befehl wieder aus den Kommittments herausgenommen werden.

Die Befehle für Revert und Reset kann ich aus der englischen Erklärung heraus nicht gut verstehen. Reset ist auf jeden Fall eine eher extreme Maßnahme. Beide Befehle benötigen immer die ID des Kommitments.

Die Erstellung von Branches (Zweige oder Äste eine Baumes) ist die wohl wichtigste Eigenschaft von Git.

Neben dem Master-Branch (Info: Master wurde zu Main auf GitHub umbenannt) können beliebig viele Branches angelegt werden.

Branches sind notwendig, um neuen Code erst zu testen. Sollte er dem Projekt und den Anforderungen genügen, kann der Branch mit dem Master-Branch zusammengeführt (gemerged) werden.

Einen neuen Branch erstellen

Code:
git branch neuerbranch

Mit dem vorgenannten Befehl wurde ein Branch erstellt.

Code:
git branch -a

Um feststellen zu können, welche Branches vorhanden sind, muss obiger Befehl abgesetzt werden.

Wenn dieser Befehl abgesetzt wird, werden alle Branches gezeigt, auch der Master-Branch. Durch ein vorangestelltes Sternchen ist zu erkennen, welcher Branch gerade der aktive ist, zu dem etwas in die Staging-Area eingestellt werden kann.

Es ist wichtig, dass man sich nicht vertut und den falschen Branch bearbeitet.

Code:
git checkout neuerbranch

Damit wechselt (switcht) Git vom derzeitigen aktiven Branch zum neu ausgewählten Branch.

In diesem Branch kann all das gemacht werden, was oben beschrieben ist. Allerdings ist zu beachten, dass dieser Branch isoliert ist, da er mit dem Master-Branch nicht in Verbindung steht.

Man kann auch einen neuen Branch anlegen und diesen direkt als aktiven Branch kennzeichnen.

Code:
git checkout -b ganzneuerbranch

Damit wird der Branch angelegt und direkt aktiviert.

Einen Branch löschen

Code:
git branch -D neuerbranch

Sollte es sein, dass ein Branch bzw. dessen Dateien, nicht mit dem Master-Branch zusammengeführt werden sollen, dann dieser Branch mit der Option "-D" gelöscht werden. Wichtig ist das **große D**.

Das Zusammenführen von Branches ist wichtig, um die Arbeit anderer in den Master-Branch einzufügen.

Das sollte natürlich nur geschehen, wenn der Code richtig ist.

Um Branches in den Master-Branch bzw. den Branch, der die anderen Branches aufnehmen soll, einzufügen, muss der aufnehmende Branch aktiv sein.

Code:
git merge ganzneuerbranch

Damit wird der Branch in den Master-Branch gemerged, da der Master-Branch der aktive Branch ist.

Anmerkung:

Der Begriff Master wurde mittlerweile auf Github mit dem Begriff Main ersetzt.