„README.md“ ändern

Ich bin meinem Grammatikfetisch erlegen und habe ein paar syntaktische Aenderungen vorgenommen :)
This commit is contained in:
emwe 2021-06-12 20:08:01 +02:00
parent 9c8516d118
commit 1d04501875

View File

@ -1,30 +1,30 @@
# Willkommen
Ich habe dieses Repository angelegt, damit wir damit ein bisschen Spielen koennen. Noch ist es leer aber ich hoffe, wir fuellen es bald.
Ich habe dieses Repository angelegt, damit wir damit ein bisschen spielen koennen. Noch ist es leer aber ich hoffe, wir fuellen es bald.
Ich wuerde gerne auf ein bisschemn git-Terminologie eingehen.
## Was ist git?
git ist eine Software zur "verteilten Versionsverwaltung von Dateien" sagt wikipedia. Genauer bedeutet das, das ich verschiedene Versionen einer Datei verwalten kann. Und das geht eben auch auf verschiedenen Rechnern.
git ist eine Software zur "verteilten Versionsverwaltung von Dateien" sagt wikipedia. Genauer bedeutet das, dass ich verschiedene Versionen einer Datei verwalten kann. Und das geht eben auch auf verschiedenen Rechnern.
Ein praktisches Beispiel waere folgendes Problem: "Ich moechte mit mehreren Leuten ein Buch schreiben"
(Damit das passt gibt es eine Bedingung: Es muss eine Datei sein.)
(Damit das passt, gibt es eine Bedingung: Es muss eine Datei sein.)
(Keine Angst, ich erklaere Fachwoerter noch)
Jetzt wuerden wir, herkoemmlich, alle staendig diese Datei austauschen, damit alle auf dem neuesten Stand sind und es wuerden so sachen passieren wie "datei3_jetzt_aber_wirklich.txt"..
Jetzt wuerden wir, herkoemmlich, alle staendig diese Datei austauschen, damit alle auf dem neuesten Stand sind und es wuerden so sachen passieren wie "datei3_jetzt_aber_wirklich.txt" ...
Da kommt dann git ins Spiel. In diesem Szenario wuerde ich einen Repository als ultimative Instanz definieren. Zb. dieses Repository hier "Spielwiese". Das kann man bei github machen, besser gitlab, besser selber hosten. (Es gibt auch faelle, wo man sowas gar nicht braucht. Zb. wenn man nur fuer sich etwas versionsverwalten will auf dem eigenen Rechner. Zb. die Rezptedatenbank. Oder die Kontakte oder oder.)
Da kommt dann git ins Spiel. In diesem Szenario wuerde ich einen Repository als ultimative Instanz definieren. Z. B. dieses Repository hier "Spielwiese". Das kann man bei github machen, besser gitlab, besser selber hosten. (Es gibt auch Faelle, wo man sowas gar nicht braucht. Z. B. wenn man nur fuer sich etwas versionsverwalten will auf dem eigenen Rechner. Z. B. die Rezeptedatenbank. Oder die Kontakte oder oder ...)
Die Leute, die dann an dem Buch mitarbeiten, "forken" sich das Repository damit sie eine Kopie in ihrem eigenen Account haben. Im optimalfall "clonen" sich die Leute das dann von ihren Accounts auf den eigenen Rechner um da dann an den Dateien Arbeiten zu koennen.
Die Leute, die dann an dem Buch mitarbeiten, "forken" sich das Repository damit sie eine Kopie in ihrem eigenen Account haben. Im optimalfall "clonen" sich die Leute das dann von ihren Accounts auf den eigenen Rechner um da dann an den Dateien arbeiten zu koennen.
Sinnvoll waere jetzt einen "branch" anzulegen. Ein "branch" ist, quasi, eine Kopie der Daten im gleichen Ordner, der ich einen Namen geben kann. Pro "repository" gibt es immer mindestens einen Branch, der frueher "master" hiess, mittlerweile setzt sich aber "main" durch. Ich lege nun einen "branch" namens "kapitel-2" an und schreibe mein Kapitel in die Datei (zb. Buch.txt).
Sinnvoll waere jetzt einen "branch" anzulegen. Ein "branch" ist, quasi, eine Kopie der Daten im gleichen Ordner, der ich einen Namen geben kann. Pro "repository" gibt es immer mindestens einen Branch, der frueher "master" hiess, mittlerweile setzt sich aber "main" durch. Ich lege nun einen "branch" namens "kapitel-2" an und schreibe mein Kapitel in die Datei (Z. B. Buch.txt).
Wenn ich dann mit der Aenderung fertig bin, muss ich diese "committen". Das ist ein elementares Ding bei git, daher gehe ich da etwas ausfuehrlicher drauf ein.
Eine der wichtigen Dinge, beim verteilten Arbeiten an einem Material, ist die Nachverfolgbarkeit von Aenderungen. Dafuer hat git ein sogenanntes "log" aller Aenderungen. In diesem log stehen auf den ersten Blick aber nicht alle Aenderungen im Detail, sondern nur Zusammenfassungen der Aenderungen.
Ich gehe zu unserem Beispiel zurueck und werde noch etwas genauer ab dem Punkt, wo ich denke, das meine Aenderung am Buch fertig ist.
Ich gehe zu unserem Beispiel zurueck und werde noch etwas genauer ab dem Punkt, wo ich denke, dass meine Aenderung am Buch fertig ist.
Ich nehme ja an, die Datei heisst "Buch.txt" und ich wollte Kapitel 2 hinzufuegen. Nachdem ich damit fertig bin, sage ich git mit einem Befehl, welche Datei in diesen "commit" soll. Das kann von einer Datei bis hin zu allen Dateien sein. Danach gebe ich dann dem commit seine Beschreibung. In diesem Falle wuerde eine commitmessage wie "Kapitel 2 hinzugefuegt" wohl passend sein.
Nun muss ich das noch in meinen Account auf dem Server hochladen und von da aus die Aenderung vorschlagen. Wenn die Person, der das Hauptrepository gehoert, mit der Aenderung zufrieden ist, kann sie diese dann in den Hauptzweig des Projektes "mergen".