main (#4)

konzept_commit_history.md: initialised

README.md: fix missing explanation for pushing

Reviewed-on: Bunteshaus/spielwiese#4
Co-Authored-By: teldra <teldra@rotce.de>
Co-Committed-By: teldra <teldra@rotce.de>

README.md

@@ -38,6 +38,7 @@ Nun muss ich das noch in meinen Account auf dem Server hochladen und von da aus
 - branch: eine Abspaltung vom vorherigen Arbeitszweig
 - merge: Das Zusammenfuegen der commits von zwei Arbeitszweigen.
 - commit: Zusammenschluss von Aenderungen unter einer Beschreibung.
+- pushen: das hochladen eines branches zum repo, von dem geklont wurde.
 - 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.
 

konzept_commit_history.md

@@ -0,0 +1,52 @@
+# History
+
+
+Ein wichtiges Konzept von Git ist die History.
+Stellen wir uns das wie einen Zeitstrahl vor.
+Unten ist aelter, oben ist aktueller.
+
+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 folgendes 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..