4.0 KiB
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.