spielwiese/konzept_commit_history.md

# 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 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.