<![CDATA[Joopi - Git]]> https://forum.hermann-splitthoff.de/ Thu, 23 Apr 2026 08:47:48 +0000 MyBB <![CDATA[Mitschrift Kurs 20210829]]> https://forum.hermann-splitthoff.de/showthread.php?tid=1383 Sat, 23 Nov 2024 22:09:03 +0100 Joopi]]> https://forum.hermann-splitthoff.de/showthread.php?tid=1383 Git-Kurs

Git

Git konfigurieren auf der Konsole:

Code:
git config --global user.name "Jopii"
git config --global user.email "info@jopii.de"
git config --global core.editor "nano"

mit

Code:
pwd

das aktuelle Arbeitsverzeichnis anzeigen lassen.

Ein neues Repository im aktuellen Verzeichnis erstellen:

Code:
git init

Damit wird ein versteckter Ordner .git erzeugt.

Prüfen, in welchem Zustand die Dateien sind:

Code:
git status

Zeigt z.B. welche Dateien geändert wurden und vieles mehr.

In der Staging Area werden Commits angelegt (Commits sind quasi kleine Versionsbunker).

Eine Datei oder einen Ordner der Staging Area hinzufügen:

Code:
git add <file>
git add <folder>
git add . (mit dem Punkt wird alles hinzugefügt, was da ist)

Eine mit add zugefügte Datei aus der Staging Area entfernen:

Code:
git rm --cached <file>

Das Hinzufügen wird quasi rückgängig gemacht.

Eine mit add hinzugefügte Datei kann weiterhin bearbeitet werden.

Code:
git status

Im Status wird gezeigt, dass die Datei in der Staging Aarea ist, aber geändert wurde (**add** wieder ausführen oder **restore**, um Änderungen zu verwerfen)

Um Datei oder Ordner in ein Repository zu bringen:

Code:
git commit -m <message>

Die Option -m muss von einer Erklärung zum Commit-Inhalt, meist sind es Änderungen, gefolgt ausgeführt werden.

Wenn git commit ohne Option aufgerufen wird, dann öffnet sich eine Datei, in die man dann den gewünschten Text oben als kurzer Titel und dann als Langtext schreiben kann.

Kurze Änderungsmitteilungen werden über die Option -m gefolgt von "Nachrichtentext" in das Repository übernommen.

Änderung im Commit bzw. im Repository anzeigen lassen (Commit-Historie):

Code:
git log

Das ist die normale Ausgabe.

Code:
git log -p

Zeigt mehr Änderungen in den Einzelheiten, also sehr ausführlich.

Code:
git log --online

Eher verkürzte Darstellung der Änderungen in einer Zeile.
 
Commits abändern, weil doch noch nicht richtig (immer nur lokal verwenden, wenn es sein muss).

Code:
git commit --amend

Der letzte Commit wird demnach überschrieben. Bei Remote-Repositories ist das nicht gut.

Wie arbeitet ".gitignore"?

Es wird eine Datei mit dem Namen ".gitignore" angelegt, in der z.B. ganze Pfade oder eben auch nur Dateien eingetragen werden, die vom Commit ausgenommen werden sollen. Das könnn z.B. auch Dateien sein, in denen Zugangsparameter für Datenbanken enthalten sind oder andere sensible Daten.

Es können auch Datei-Extensions wie *.txt genutzt werden.

Man kann die Datei .gitignore selber schreiben. Aber man kann auch auf vorgefertige Dateien auf GitHub zugreifen: .gitignore

Diese Ignore-Dateien sind themenspezifisch vorhanden. Könnte später mal interessant sein.

Alle Änderungen au der Staging Aarea herausnehmen (das Gegenteil von add - unstaging):

Code:
git reset

das betrifft alle Dateien

Code:
git reset <filename>

betrifft nur die angegebene Datei

Wenn man den reset-Befehl mit der 7-stelligen ID des Commits ausführt, wird das ganze Commit zurückgesetzt.

Alle Änderungen in der Datei Zeile für Zeile anzeigen lassen:

Code:
git blame <files>
git blame --color-lines <filename>

GitHub

In GitHub wurde aus master nun main, wenn es um den Hauptzweig geht.

Das ist dann wichtig, wenn ein Repository konfiguriert wird.

Remote-Repositories clonen:

Code:
git clone <url>

Das gilt auch für eigene Projekte, wenn das lokale git nicht mehr zuständig ist, sondern alles auf github liegt.

Code:
git remote -v

Zeigt an, welche remote Repositories getrackt werden.
 
Bei git status wird angezeigt branch master und origin/master. Der erste Master ist der lokale, der zweite Master (oder main) ist der Master vom Clone!

Prüfen, welche Branches vorhanden sind:

Code:
git branch
git branch -v
git branch -vv

(zeigt an, welchen origin/master er trackt

 Herunterladen von Commits und Branches von einem remote Repository:

Code:
git fetch

 Wenn der Clone weiter ist, da mit fetch die Neuerungen geholt wurden, wird mit dem lokalen Master zusammengeführt:

Code:
git merge origin/master

Wenn ich alleine an dem Projekt arbeiten, benötige ich die obigen Möglichkeiten nicht (nur push zum Hochladen).

GitHub für eigene Projekte

Es muss ein Account auf GitHub vorhanden sein.
Das Repository muss einen Namen haben: orbitjopii

Um das lokale Repository auf GitHub zu bringen muss es heißen:

Code:
git remote add origin https:/...../orbitjopii.git

 Um dann die Daten aus dem lokalen Repository in das remote Repository zu bekommen, muss es heßen:

Code:
git push -u origin master bzw. main

Push muss auch später genutzt werden.

Änderungen zu GitHub übertragen:

Code:
git add ...

Code:
git commit -m message

Code:
git log --oneline --branches --remotes --graph

Code:
git push

Code:
git branch -vv

Prüfen, ob die Änderung im origin/master angekommen ist.
 
Code:
git log --oneline --branches --remotes --graph

Auch hier kann man prüfen, ob master und origin/master gleich sind.
 
Code:
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git pull origin
Username for 'https://github.com': xxx
Password for 'https://Janiekmulder@github.com':
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Entpacke Objekte: 100% (3/3), 858 Bytes | 858.00 KiB/s, fertig.
Von https://github.com/Janiekmulder/kleinerorbit
  0f8763f..192422c  main      -> origin/main
Merge made by the 'recursive' strategy.
README.md | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 README.md

Code:
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git branch -vv
* main 7c007ff [origin/main: 2 voraus] Merge branch 'main' of https://github.com/Janiekmulder/kleinerorbit into main
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ ls -al
insgesamt 24
drwxrwxr-x 3 xxx xxx 4096 Aug 28 20:59 .
drwxrwxr-x 6 xxx xxx 4096 Aug 28 20:29 ..
drwxrwxr-x 8 xxx xxx 4096 Aug 28 21:01 .git
-rw-rw-r-- 1 xxx xxx  38 Aug 28 18:09 .gitignore
-rw-rw-r-- 1 xxx xxx  491 Aug 28 20:56 index.html
-rw-rw-r-- 1 xxx xxx  169 Aug 28 20:59 README.md
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git push origin
Username for 'https://github.com': xxx
Password for 'https://xxxx@github.com':
Objekte aufzählen: 9, fertig.
Zähle Objekte: 100% (8/8), fertig.
Delta-Kompression verwendet bis zu 16 Threads.
Komprimiere Objekte: 100% (5/5), fertig.
Schreibe Objekte: 100% (5/5), 897 Bytes | 897.00 KiB/s, fertig.
Gesamt 5 (Delta 1), Wiederverwendet 0 (Delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/Janiekmulder/kleinerorbit.git
  192422c..7c007ff  main -> main
 
Mitschrift Shellscript von Bryan Jenks wegen Cronjob, der Shell ausführt und Git/GitHub aktualisiert

Code:
ZK_PATH="Pfad zum Vault"

cd "$ZK_PATH"

git pull

CHANGES_EXISTS="$(git status --porcelain | wc -l)"

if [ "$CHANGES_EXISTS" -eq @ ]; then
  exit @
fi

git pull
git add .
git commit -q -m "Last Sync: $(date +'%Y.%m-%d %H:%M:$X')"
git push -q

How to git push using gitHub token on the command line:

Code:
git push https://<GITHUB_ACCESS_TOKEN>@github.com/<GITHUB_USERNAME>/<REPOSITORY_NAME>.git

Code:
git push https://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@github.com/Janiekmulder/orbit2.git

Neuer Versuch am 29.08.2021 um 10:48 Uhr

…or push an existing repository from the command line:

Code:
git remote add origin https://github.com/Janiekmulder/orbit2.git
git branch -M main
git push -u origin main

Alle Anweisungen, wenn ein neues Repository nackt erstellt wurde.

Quick setup — if you’ve done this kind of thing before
or
https://github.com/Janiekmulder/orbit2.git

Get started by creating a new file or uploading an existing file. We recommend every repository include a README, LICENSE, and .gitignore.

…or create a new repository on the command line

Code:
echo "# orbit2" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/Janiekmulder/orbit2.git
git push -u origin main

…or push an existing repository from the command line

Code:
git remote add origin https://github.com/Janiekmulder/orbit2.git
git branch -M main
git push -u origin main

Code:
git push https://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@github.com/Janiekmulder/orbitjopii.git
]]> Git-Kurs

Git

Git konfigurieren auf der Konsole:

Code:
git config --global user.name "Jopii"
git config --global user.email "info@jopii.de"
git config --global core.editor "nano"

mit

Code:
pwd

das aktuelle Arbeitsverzeichnis anzeigen lassen.

Ein neues Repository im aktuellen Verzeichnis erstellen:

Code:
git init

Damit wird ein versteckter Ordner .git erzeugt.

Prüfen, in welchem Zustand die Dateien sind:

Code:
git status

Zeigt z.B. welche Dateien geändert wurden und vieles mehr.

In der Staging Area werden Commits angelegt (Commits sind quasi kleine Versionsbunker).

Eine Datei oder einen Ordner der Staging Area hinzufügen:

Code:
git add <file>
git add <folder>
git add . (mit dem Punkt wird alles hinzugefügt, was da ist)

Eine mit add zugefügte Datei aus der Staging Area entfernen:

Code:
git rm --cached <file>

Das Hinzufügen wird quasi rückgängig gemacht.

Eine mit add hinzugefügte Datei kann weiterhin bearbeitet werden.

Code:
git status

Im Status wird gezeigt, dass die Datei in der Staging Aarea ist, aber geändert wurde (**add** wieder ausführen oder **restore**, um Änderungen zu verwerfen)

Um Datei oder Ordner in ein Repository zu bringen:

Code:
git commit -m <message>

Die Option -m muss von einer Erklärung zum Commit-Inhalt, meist sind es Änderungen, gefolgt ausgeführt werden.

Wenn git commit ohne Option aufgerufen wird, dann öffnet sich eine Datei, in die man dann den gewünschten Text oben als kurzer Titel und dann als Langtext schreiben kann.

Kurze Änderungsmitteilungen werden über die Option -m gefolgt von "Nachrichtentext" in das Repository übernommen.

Änderung im Commit bzw. im Repository anzeigen lassen (Commit-Historie):

Code:
git log

Das ist die normale Ausgabe.

Code:
git log -p

Zeigt mehr Änderungen in den Einzelheiten, also sehr ausführlich.

Code:
git log --online

Eher verkürzte Darstellung der Änderungen in einer Zeile.
 
Commits abändern, weil doch noch nicht richtig (immer nur lokal verwenden, wenn es sein muss).

Code:
git commit --amend

Der letzte Commit wird demnach überschrieben. Bei Remote-Repositories ist das nicht gut.

Wie arbeitet ".gitignore"?

Es wird eine Datei mit dem Namen ".gitignore" angelegt, in der z.B. ganze Pfade oder eben auch nur Dateien eingetragen werden, die vom Commit ausgenommen werden sollen. Das könnn z.B. auch Dateien sein, in denen Zugangsparameter für Datenbanken enthalten sind oder andere sensible Daten.

Es können auch Datei-Extensions wie *.txt genutzt werden.

Man kann die Datei .gitignore selber schreiben. Aber man kann auch auf vorgefertige Dateien auf GitHub zugreifen: .gitignore

Diese Ignore-Dateien sind themenspezifisch vorhanden. Könnte später mal interessant sein.

Alle Änderungen au der Staging Aarea herausnehmen (das Gegenteil von add - unstaging):

Code:
git reset

das betrifft alle Dateien

Code:
git reset <filename>

betrifft nur die angegebene Datei

Wenn man den reset-Befehl mit der 7-stelligen ID des Commits ausführt, wird das ganze Commit zurückgesetzt.

Alle Änderungen in der Datei Zeile für Zeile anzeigen lassen:

Code:
git blame <files>
git blame --color-lines <filename>

GitHub

In GitHub wurde aus master nun main, wenn es um den Hauptzweig geht.

Das ist dann wichtig, wenn ein Repository konfiguriert wird.

Remote-Repositories clonen:

Code:
git clone <url>

Das gilt auch für eigene Projekte, wenn das lokale git nicht mehr zuständig ist, sondern alles auf github liegt.

Code:
git remote -v

Zeigt an, welche remote Repositories getrackt werden.
 
Bei git status wird angezeigt branch master und origin/master. Der erste Master ist der lokale, der zweite Master (oder main) ist der Master vom Clone!

Prüfen, welche Branches vorhanden sind:

Code:
git branch
git branch -v
git branch -vv

(zeigt an, welchen origin/master er trackt

 Herunterladen von Commits und Branches von einem remote Repository:

Code:
git fetch

 Wenn der Clone weiter ist, da mit fetch die Neuerungen geholt wurden, wird mit dem lokalen Master zusammengeführt:

Code:
git merge origin/master

Wenn ich alleine an dem Projekt arbeiten, benötige ich die obigen Möglichkeiten nicht (nur push zum Hochladen).

GitHub für eigene Projekte

Es muss ein Account auf GitHub vorhanden sein.
Das Repository muss einen Namen haben: orbitjopii

Um das lokale Repository auf GitHub zu bringen muss es heißen:

Code:
git remote add origin https:/...../orbitjopii.git

 Um dann die Daten aus dem lokalen Repository in das remote Repository zu bekommen, muss es heßen:

Code:
git push -u origin master bzw. main

Push muss auch später genutzt werden.

Änderungen zu GitHub übertragen:

Code:
git add ...

Code:
git commit -m message

Code:
git log --oneline --branches --remotes --graph

Code:
git push

Code:
git branch -vv

Prüfen, ob die Änderung im origin/master angekommen ist.
 
Code:
git log --oneline --branches --remotes --graph

Auch hier kann man prüfen, ob master und origin/master gleich sind.
 
Code:
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git pull origin
Username for 'https://github.com': xxx
Password for 'https://Janiekmulder@github.com':
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Entpacke Objekte: 100% (3/3), 858 Bytes | 858.00 KiB/s, fertig.
Von https://github.com/Janiekmulder/kleinerorbit
  0f8763f..192422c  main      -> origin/main
Merge made by the 'recursive' strategy.
README.md | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 README.md

Code:
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git branch -vv
* main 7c007ff [origin/main: 2 voraus] Merge branch 'main' of https://github.com/Janiekmulder/kleinerorbit into main
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ ls -al
insgesamt 24
drwxrwxr-x 3 xxx xxx 4096 Aug 28 20:59 .
drwxrwxr-x 6 xxx xxx 4096 Aug 28 20:29 ..
drwxrwxr-x 8 xxx xxx 4096 Aug 28 21:01 .git
-rw-rw-r-- 1 xxx xxx  38 Aug 28 18:09 .gitignore
-rw-rw-r-- 1 xxx xxx  491 Aug 28 20:56 index.html
-rw-rw-r-- 1 xxx xxx  169 Aug 28 20:59 README.md
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git push origin
Username for 'https://github.com': xxx
Password for 'https://xxxx@github.com':
Objekte aufzählen: 9, fertig.
Zähle Objekte: 100% (8/8), fertig.
Delta-Kompression verwendet bis zu 16 Threads.
Komprimiere Objekte: 100% (5/5), fertig.
Schreibe Objekte: 100% (5/5), 897 Bytes | 897.00 KiB/s, fertig.
Gesamt 5 (Delta 1), Wiederverwendet 0 (Delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/Janiekmulder/kleinerorbit.git
  192422c..7c007ff  main -> main
 
Mitschrift Shellscript von Bryan Jenks wegen Cronjob, der Shell ausführt und Git/GitHub aktualisiert

Code:
ZK_PATH="Pfad zum Vault"

cd "$ZK_PATH"

git pull

CHANGES_EXISTS="$(git status --porcelain | wc -l)"

if [ "$CHANGES_EXISTS" -eq @ ]; then
  exit @
fi

git pull
git add .
git commit -q -m "Last Sync: $(date +'%Y.%m-%d %H:%M:$X')"
git push -q

How to git push using gitHub token on the command line:

Code:
git push https://<GITHUB_ACCESS_TOKEN>@github.com/<GITHUB_USERNAME>/<REPOSITORY_NAME>.git

Code:
git push https://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@github.com/Janiekmulder/orbit2.git

Neuer Versuch am 29.08.2021 um 10:48 Uhr

…or push an existing repository from the command line:

Code:
git remote add origin https://github.com/Janiekmulder/orbit2.git
git branch -M main
git push -u origin main

Alle Anweisungen, wenn ein neues Repository nackt erstellt wurde.

Quick setup — if you’ve done this kind of thing before
or
https://github.com/Janiekmulder/orbit2.git

Get started by creating a new file or uploading an existing file. We recommend every repository include a README, LICENSE, and .gitignore.

…or create a new repository on the command line

Code:
echo "# orbit2" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/Janiekmulder/orbit2.git
git push -u origin main

…or push an existing repository from the command line

Code:
git remote add origin https://github.com/Janiekmulder/orbit2.git
git branch -M main
git push -u origin main

Code:
git push https://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@github.com/Janiekmulder/orbitjopii.git
]]> <![CDATA[Das Git-MOC]]> https://forum.hermann-splitthoff.de/showthread.php?tid=1382 Sat, 23 Nov 2024 21:53:36 +0100 Joopi]]> https://forum.hermann-splitthoff.de/showthread.php?tid=1382 Das MOC für Git

clone Repository - Wie wird ein Github-Repository gecloned?
submodul Repository - Wie wird ein Submodul installiert?
Doku Git und GitHub - Meine Dokumentation von 15.11.2020
Mitschrift Udemy-Kurs 20210829 - Den Udemy-Kurs habe ich komplett durch und Notizen gemacht.
Git Submodul clonen - clone oder submodule add? Wo ist der Unterschied.]]> Das MOC für Git

clone Repository - Wie wird ein Github-Repository gecloned?
submodul Repository - Wie wird ein Submodul installiert?
Doku Git und GitHub - Meine Dokumentation von 15.11.2020
Mitschrift Udemy-Kurs 20210829 - Den Udemy-Kurs habe ich komplett durch und Notizen gemacht.
Git Submodul clonen - clone oder submodule add? Wo ist der Unterschied.]]> <![CDATA[Doku Git und GitHub]]> https://forum.hermann-splitthoff.de/showthread.php?tid=52 Sat, 07 Jan 2023 13:20:19 +0100 Joopi]]> https://forum.hermann-splitthoff.de/showthread.php?tid=52
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.]]>
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.]]> <![CDATA[Git Submodul clonen]]> https://forum.hermann-splitthoff.de/showthread.php?tid=51 Sat, 07 Jan 2023 13:03:49 +0100 Joopi]]> https://forum.hermann-splitthoff.de/showthread.php?tid=51
Zitat:fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /media/django)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).

Es hat dann tatsächlich drei, vier Sekunden gedauert bis mir klar geworden war, dass ich noch kein Git-Repository für die neue Hugotestseite erstellt hatte.

Mit

Code:
git init
git add .
git commit -m "blablabla"

wurde das Repository erstellt und schon funktionierte der Befehl im root-Verzeichnis der Hugoseite, um ein Submodule hinzuzufügen:

Code:
git submodule add https://github.com/hugo-toha/toha.git themes/toha
git submodule init
git submodule update

Dann ist mir eingefallen, dass bei der Nutzung von Submodulen, direkt Updates vom Theme heruntergeladen werden können:

Code:
git submodule update --remote themes/toha

Es muss aber einen Grund geben, warum der Themeautor die Info herausgegeben hat, dass das Theme als Submodule zu installieren ist und der normale Clone-Befehl das Theme nicht gut unterstützt.

Wichtig ist für mich zu wissen, und ich sollte es auch behalten, dass bei der Nutzung von Submodulen ein Git-Repository vonnöten ist. :-)]]>
Zitat:fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /media/django)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).

Es hat dann tatsächlich drei, vier Sekunden gedauert bis mir klar geworden war, dass ich noch kein Git-Repository für die neue Hugotestseite erstellt hatte.

Mit

Code:
git init
git add .
git commit -m "blablabla"

wurde das Repository erstellt und schon funktionierte der Befehl im root-Verzeichnis der Hugoseite, um ein Submodule hinzuzufügen:

Code:
git submodule add https://github.com/hugo-toha/toha.git themes/toha
git submodule init
git submodule update

Dann ist mir eingefallen, dass bei der Nutzung von Submodulen, direkt Updates vom Theme heruntergeladen werden können:

Code:
git submodule update --remote themes/toha

Es muss aber einen Grund geben, warum der Themeautor die Info herausgegeben hat, dass das Theme als Submodule zu installieren ist und der normale Clone-Befehl das Theme nicht gut unterstützt.

Wichtig ist für mich zu wissen, und ich sollte es auch behalten, dass bei der Nutzung von Submodulen ein Git-Repository vonnöten ist. :-)]]> <![CDATA[submodul Repository]]> https://forum.hermann-splitthoff.de/showthread.php?tid=50 Sat, 07 Jan 2023 13:00:48 +0100 Joopi]]> https://forum.hermann-splitthoff.de/showthread.php?tid=50
Am besten wechselt man direkt in den Ordner der Hugo-Seite und setzt dann den entsprechenden Befehl ab.

Die Syntax für den Download eines Submoduls ist wie folgt:

Code:
git init
git submodule add https://github.com/budparr/gohugo-theme-ananke.git ./themes/ananke

Danach ist das Theme in Hugo bzw. in der Datei config.toml einzubinden:

Code:
echo ‘theme = “ananke”’ >> config.toml
]]>
Am besten wechselt man direkt in den Ordner der Hugo-Seite und setzt dann den entsprechenden Befehl ab.

Die Syntax für den Download eines Submoduls ist wie folgt:

Code:
git init
git submodule add https://github.com/budparr/gohugo-theme-ananke.git ./themes/ananke

Danach ist das Theme in Hugo bzw. in der Datei config.toml einzubinden:

Code:
echo ‘theme = “ananke”’ >> config.toml
]]> <![CDATA[clone Repository]]> https://forum.hermann-splitthoff.de/showthread.php?tid=49 Sat, 07 Jan 2023 12:59:16 +0100 Joopi]]> https://forum.hermann-splitthoff.de/showthread.php?tid=49
Bezogen auf ein zu clonendes Theme für Hugo könnte man wie folgt vorgehen, indem man sich im Ordner der Hugoseite befindet und dann folgenden Befehl absetzt:

Code:
git clone URL-des-Repositorys ./themes/Themename

Es ist in diesem Falle notwendig, dass der versteckte Ordner .git, der versteckt ist, gelöscht wird.


Ansonsten, sollte der Clone mit Git organisiert werden, muss der versteckte Ordner natürlich bestehen bleiben.]]>
Bezogen auf ein zu clonendes Theme für Hugo könnte man wie folgt vorgehen, indem man sich im Ordner der Hugoseite befindet und dann folgenden Befehl absetzt:

Code:
git clone URL-des-Repositorys ./themes/Themename

Es ist in diesem Falle notwendig, dass der versteckte Ordner .git, der versteckt ist, gelöscht wird.


Ansonsten, sollte der Clone mit Git organisiert werden, muss der versteckte Ordner natürlich bestehen bleiben.]]>