README.md fix toc

Da das repo nichmehr leer ist, stimmt das halt nicht mehr.

README.md

@@ -1,9 +1,14 @@
 # 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.  
 
+TOC:  
+[Was ist git?](#was-ist-git)  
+[Begriffe](#begriffe)  
+[Erste Schritte](#erste-schritte)  
+[Zweiter Schritt](#zweiter-schritt)  
+
 ## Was ist git?
 
 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.
@@ -31,16 +36,30 @@ Nun muss ich das noch in meinen Account auf dem Server hochladen und von da aus
 
 ** Keine Angst. Das ist nur ein Ueberblick. Wir werden das nach und nach durchgehen! **
 
-## Begriffe (todo)
+[hier noch ein versuch der zusammenfassung](konzept_commit_history.md)  
+[hier das git buch](https://git-scm.com/book/de/v2)
 
-- clone: Eine lokale Kopie eines repos.
-- fork: Eine entfernte Kopie eines repos.
-- branch: eine Abspaltung vom vorherigen Arbeitszweig
+## Begriffe
+
+- [repository (repo)](git/repo.md): Ein Container wo alles zum Projekt gehoerende drin ist. Kann lokal und remote sein.
+- [fork](git/fork.md): (M)Ein fork ist (M)Eine Kopie des originalen Repositorys. (idr ein clone vorgang auf dem Server.)
+- [clone](git/clone.md): Ist der Vorgang, ein repo zu kopieren. (idr benutzt um ein repo auf den eigenen Pc zu kopieren)
+- [pushen](git/push.md): das hochladen eines branches zum repo, von dem geklont wurde.
+- [pull-request (pr)](git/pr.md): Das Anbieten von Aenderungen am Material. 
+- branch: Ein Arbeitszweig in einem repo. Ein Arbeitszweig ist der Name der Versionsgeschichte der Dateien im repo.
 - merge: Das Zusammenfuegen der commits von zwei Arbeitszweigen.
 - commit: Zusammenschluss von Aenderungen unter einer Beschreibung.
-- pull-request (pr): Das Anbieten von Aenderungen am Material. 
-- repository (repo): Ein Container wo alles zum Projekt gehoerende drin ist. Kann lokal und remote sein.
 
 ## Erste Schritte
 
-Das erste, was Du jetzt tun kannst ist, dieses repo zu forken. Als Hinweis: Ganz rechts oben sollte "Fork" stehen.
+Das erste, was Du jetzt tun kannst ist, dieses repo zu forken. Als Hinweis: Ganz rechts oben sollte "Fork" stehen.
+
+Damit wird eine Kopie dieses Repositorys in deinem Account angelegt. Deine Kopie wird bei Aenderungen in diesem Original nicht geupdated, das muss manuell passieren. Dazu spaeter mehr.
+
+![Screenshot 1][sc1]
+
+[sc1]: https://schlomp.space/Bunteshaus/spielwiese/raw/branch/main/media/sc1.png
+
+## Zweiter Schritt
+
+Wenn du git effizient nutzen willst, musst du es einstellen. [Lies hier](git-konfigurieren.md) um mehr zu erfahren.

git-konfigurieren.md

@@ -0,0 +1,48 @@
+# Schritt zwei
+
+## git installieren
+
+`sudo apt install git`
+
+oder 
+
+`sudo xbps-install -S git`
+
+im terminal ausfuehren
+
+## git konfigurieren
+
+### Allgemeines
+
+Um git sinnvoll nutzen zu koennen, muss git konfiguriert werden.
+
+Es gibt zwei Arten von Konfigurationsoptionen. "globale" und "per repository".
+
+Wenn ich eine Option global setze, gilt die fuer alle Repositorys die ich benutze.
+
+Nenn ich mich zum Neispiel "purzelbaumwesen" und moechte auch ueberall, wo ich
+mit git arbeite, so erkannt werden, setze ich das global.
+
+Es gibt aber dann doch ein Repository, da moechte ich mit, zB., meinem Realnamen 
+erkannt werden. Das ist Beispielsweise bei der Linuxentwicklung so. Dann kann
+ich das auch nur fuer ein jeweiliges Repository einstellen.
+
+### Namen
+
+Die zwei wichtigsten Optionen sind wohl der, wie erwaehnt, Name und die Emailadresse.
+
+ `git config --global user.name "purzelbaumwesen"`  
+ `git config --global user.email "purzelbaumwesen@beispiel.org"`
+
+ Waere ein Beispiel fuer zwei Befehle, um die beiden "Credentials", wie das Flag "--global" andeutet, global
+ einzustellen.
+
+ Wuerde das "--global" weggelassen werden, waere es nur fuer das Repository in dem man sich befindet, also nicht global.
+
+### Rebase ist Standard bei einem pull
+
+Was auch immer das bedeutet. Ist auch egal. Das ist eine Option, bei der ich nicht genau weiss, was sie macht. Aber ich weiss von vielen Leuten, die verzweifeln, weil diese nicht Standard ist.
+
+`git config --global pull.rebase true`
+
+Wenn diese Optionen gesetzt sind, sollte alles klar sein um durchzustarten. :)

git/clone.md

@@ -0,0 +1,15 @@
+# clone
+
+Das bezeichnet allgemein den Vorgang des kopierens bei git.
+
+Wen ich ein repo zb. bei github forke, passiert da intern ein cloning.
+
+Wenn ich meinen fork eines repos auf meinem Rechner haben will, clone ich den.
+
+Ich kann auch das original repo direkt clonen (das erschwert aber
+Mitarbeit am Projekt. Hab da aber keine wirkliche Idee, warum man das machen sollte)
+
+`git clone https://schlomp.space/teldra/spielwiese` wuerde ich ausfuehren,
+was dazu fuehrt, das ein neuer Ordner, im aktuellen Ordner, existiert, mit dem Namen des repos,
+also "spielwiese". Damit haette ich meinen fork der spielwiese auf meinem Rechner.
+

git/fork.md

@@ -0,0 +1,11 @@
+# Fork
+
+Ein fork ist eine Abspaltung vom originalen repo.  
+Ich kann entweder meine eigenen oder oeffentliche repos von anderen Leuten forken.
+
+Ich kann so einen fork vornehmen, weil ich eine komplett eigene Vision des originalen
+Projektes entwickeln will aber auch um mit dem originalen Projekt zusammen zu arbeiten.
+
+Praktisch bedeutet das eigentlich erstmal "nur", das eine Kopie der aktuellen Version des zu
+forkenden repos im eigenen Account angelegt wird. Damit habe ich das entsprechende repo
+als eigenes repo in meinem Account.

git/pr.md

@@ -0,0 +1,6 @@
+# pull reqeust
+
+Ein pull request oder auch pull-request oder pr ist ein Vorschlag einer Aenderung an ein repo.
+
+Wenn ich an einem Projekt mitarbeiten will, habe ich ja einen fork mit Aenderungen.
+Dann mache ich einen pull-request, um so die Aenderung dem Originalprojekt vorzuschlagen.

git/push.md

@@ -0,0 +1,11 @@
+# push
+
+Mit pushen bezeichnet man das hochladen von Aenderungen.  
+Es kann ueberall wo schreibrechte vorhanden sind und
+die Historys aka logs der Dateien passen, hingepusht werden.
+
+In der Regel pusht man aber nur zum eigenen repo (was ja auch ein fork sein kann).
+
+`git push` pusht den aktuellen branch auf die quelle des clones.
+
+pushen braucht es nicht bei lokalen repos.

git/repo.md

@@ -0,0 +1,38 @@
+# Repository
+
+## Zwei Arten
+Ein repo ist die Sammlung aller Projektdateien und deren Aenderungsgeschichten.  
+Es gibt davon zwei Arten: lokale und entfernte (remote).
+
+### lokale repos
+Ein lokales repo ist erstmal nur ein Ordner auf dem eigenen Rechner der unter der
+Verwaltung von git steht. Wenn der Ordner `.git` (gilt als versteckt, durch den
+Punkt am Anfang bei Linux) vorhanden ist, verwaltet git den Ordner in dem `.git`
+liegt.
+
+Das der Ordner von git verwaltet wird, kann zwei Ursachen haben. Entweder ist es
+ein clone von einem remote repo oder er wurde manuell unter die Obhut von git
+gestellt.
+
+Will ich einen Ordner zu einem lokalen git repo machen, zb. meine Rezeptesammlung,
+wechsel ich in den Ordner mit der Dateisammlung und schreib `git init`.
+Nun ist der Ordner unter der "kontrolle" von git. Jetzt sollte git bekannt gemacht
+werden, welche Dateien zu dem "Rezeptesammlungs-repo" gehoeren. Dazu spaeter mehr.
+Meistens mache ich ein lokales repo, wenn ich weiss, das ich Dateien nicht auf
+mehreren Computern brauche. Oder mit anderen zusammenarbeite.
+
+### remote repos
+Ein remote repo ist, sehr kurz gesagt, ein spezieller Ordner, von dem gecloned
+oder geforked werden kann.
+
+Ein remote repo lege ich an, wenn ich mit mehreren zusammenarbeiten will.
+`git init --bare` in einem leeren Ordner und dieser ist bereit, gecloned oder geforked
+zu werden.
+
+Das ist das, was github, gitlab oder schlomp.space machen, wenn man ein neues Repo anlegt.
+
+Man kann das auch auf dem eigenen Rechner machen um dann in einen anderen Ordner (in dem man
+dann arbeitet) auf dem selben Rechner zu clonen. Oder sonstwas zu tun. Ich wuesste
+nicht was. Ich wollt nur sagen: "Alles was man macht, wenn man mit Servern interagiert,
+kann auch nur auf dem eigenen Rechner passieren". Das ist voll flexibel, daher wieder alles
+Einzelfallabhaengig.

konzept_commit_history.md

@@ -0,0 +1,69 @@
+# History aka log
+
+
+Ein wichtiges Konzept von Git ist das log.
+Stellen wir uns das wie einen Zeitstrahl vor.
+Unten ist aelter, oben ist aktueller.
+Ich werde es im weiteren Verlauf History nennen.
+
+Egal wo ich einen Account habe, sobald ich ein Repository erstelle,
+wird damit auch der Branch "main" geboren. Und damit die vorraussetzung fuer
+die History des Branches "main". Sobald der erste Commit, der aus der Angabe, 
+welche Dateien dazugehoeren und einer Beschreibung besteht, angelegt wird,
+existiert die History des Branches "main". Der koennte jeden Namen haben aber
+main ist voreingestellt. (Frueher war der Name auf "master" eingestellt. Seit 
+der BLM Diskussion wird das umbenannt.)
+
+Das Repository stellt dabei den Container dar, in dem das Projekt bearbeitet wird.
+Man kann sich das wie einen Projektordner vorstellen wo alle Dateien drin sind,
+die zum Projekt gehoeren. (Und tatsaechlich ist es auch so.)
+
+Und git fuegt jetzt Metadaten hinzu (Wer hat wann was veraendert und wie beschrieben)
+und verfolgt, was sich an den Dateien zwischen zwei commits geaendert hat und schreibt
+das in die History des aktuellen Branches.
+
+Wir befinden uns gedanklich noch immer im Branch "main". Jetzt wechseln wir den Branch mal.
+Unsere Motivation: Wir haben das Buch fertig und wollen ein Vorwort formulieren.
+
+Wir legen also einen neuen Branch an mit dem Namen "vorwort" (anstatt "main").
+Die History des Branches "vorwort" ist aber nicht leer obwohl er gerade geboren ist.
+Da steht die Geschichte der Dateien drin, wie sie im Branch "main" ist. Nachdem drueber
+nachdenken ist es auch logisch: Wir waren in "main", sind davon divergiert aber haben noch
+nichts geaendert.
+
+Nun legen wir beispielsweise die Datei "Vorwort.txt" mit sinnvollem Inhalt an. (zb. weil
+sich drauf geeinigt wurde, das jeder Sinnzusammenhang in einer Datei ist.)
+
+Nun wuerde ich ein Commit machen, indem ich git sage, das es dazu die Aenderungen der
+Datei Vorwort.txt (das sie nun existiert ist auch eine Aenderung. ;) ) und die Beschreibung
+des Commits ("Vorwort.txt: initiiert" waere sinnvoll) in die History des Branches "vorwort"
+eintragen soll.
+
+Wir haben nun folgenden zustand: Wir haben den Branch "main" der einen Commit hinter "vorwort"
+zurueckliegt in der History der Commits.
+
+Mit dem Branch "vorwort" koennten wir nun vieles tun: Wenn wir an einem Projekt mit mehreren
+Personen teilnehmen haben wir das Projekt ja vorher geforkt und in unserem Account. Also pushen
+wir diesen Branch zu dem Repository wo er dann auch als Branch vorliegt und machen dann einen
+Pull-Request auf das urspruengliche Repository von dem geforkten Repository.
+
+Oder wir machen auf unseren eigenen "main" Branch einen Pull-Request. Oder wir mergen den
+einfach in unseren eigenen "main" Branch und machen dann einen Pull-Request auf den "main"
+des Originals. Ich weiss das hoert sich jetzt wirr an aber ab hier kommt es drauf an, was
+mensch machen will.. und vorher machte..
+
+Wir lernen im Prinzip: Ein Repsository ist eine Sammlung von Dateien wie ein Ordner.
+In diesem Ordner gibt es mindestens eine History der Dateien mit dem Namen "main" oder "master".
+Ich kann Branches anlegen, die die Geschichte des Branches enthaelt von dem wir abzweigen um
+unabhaengig vom originalen Branch Aenderungen zu machen. Die Historys verschiedener Branches mit
+gleichem Ursprung koennen zusammengefuehrt werden. Entweder direkt via merge, wenn es ein eigenes 
+Repository ist oder generell wenn Schreibrechte auf das Zielrepository vorhanden sind oder 
+via pull-request, wenn es ein fremdes Zielrepository ist bzw. wenn keine Schreibrechte vorhanden sind.
+
+Wenn es keine Konflikte gibt, passiert dann alles automatisch.
+
+Konflikte entstehen, wenn ich einen Zustand einer Datei habe, der vom Zustand der Datei die ich
+veraender im Original abweicht. Zb. weil jemand anders in der Zwischenzeit die Datei an Stellen
+geaendert hat, an denen ich Arbeitete. Das wird dann bemerkt und es werden moeglichkeiten zum loesen
+des Konfliktes angeboten. Mit einem guten Workflow und einer Einstellung fuer git wird das Risiko
+aber aus Gruenden reduziert.