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
Damit ist Git personalisiert.
Um festzustellen, welcher User für Git angelegt werde, ist folgender Befehl auf der Konsole abzusetzen.
Projekt initialisieren
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
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
Um eine Datei in die Staging-Area hinzuzufügen, bedarf es nur dem vorgenannten Befehl.
Datei aus Staging-Area löschen
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
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
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
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.
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:
Ein Kommitment zurücknehmen
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
Mit dem vorgenannten Befehl wurde ein Branch erstellt.
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.
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.
Damit wird der Branch angelegt und direkt aktiviert.
Einen Branch löschen
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.
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.
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 TuennesCode:
git config --globel user.email tuennes@yahoo.deDamit ist Git personalisiert.
Um festzustellen, welcher User für Git angelegt werde, ist folgender Befehl auf der Konsole abzusetzen.
Code:
git config user.nameProjekt initialisieren
Code:
git initMit 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 statusDieser 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.htmlUm 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.htmlSofern 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 logSobald 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 --onelineUm 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 af6b84cSofern 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 neuerbranchMit dem vorgenannten Befehl wurde ein Branch erstellt.
Code:
git branch -aUm 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 neuerbranchDamit 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 ganzneuerbranchDamit wird der Branch angelegt und direkt aktiviert.
Einen Branch löschen
Code:
git branch -D neuerbranchSollte 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 ganzneuerbranchDamit 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.