bunteshaus.de/docs/git.md

Git

Git ist eine Versionsverwaltungssoftware die supergut für Projekte geeignet ist, an denen viele Leute mitarbeiten.

Wenn wir über git sprechen, gibt es ein paar Fachbegriffe, deren Erklärung wenigstens angerissen werden muss. (genaueres Wikipedia Offizielles Git Buch)

Da wir Daten ja lagern, fangen wir mit dem Fachbegriff eines Lagers bei git an, das:

Repository

Ein R. oder kurz "repo" ist im Prinzip einfach nur ein Ordner, dessen Inhalt unter der Verwaltung von git steht. Ein repo kann Quelle und Ziel sein, wenn zb. mit einem entfernten repo gearbeitet wird.
Ein repo konkret, wie es Nutzenden meistens begegnet, besteht aus zwei Arten von Daten: Der Inhalt, der verwaltet wird und den Verwaltungsdaten von git. (Diese sind im Ordner .git im repo)

Befinde ich mich in einem Ordner, der von git verwaltet werden soll, führe ich git init aus. Nun kann ich den Verwaltungsdaten meinen Inhalt (beides siehe unter "Repository") bekanntmachen. Das mMn. wichtigste Konzept der Verwaltungsdaten von git ist das

Logbuch oder "git log"

Im Logbuch, kurz log, wird protokolliert, wer, was, wann geändert hat.
Da git vor allem darauf ausgelegt ist, das viele Menschen zusammen an einem Projekt arbeiten, ist es elementar, Änderungen am Projekt Leuten zuordnen zu können.
Dafür konfiguriert man bei git eine Identität, die aus einem Usernamen und einer Emailadresse besteht. (Dieses ist unabhängig von etwaigen Logindaten bei Hostern wie github oder schlomp, hat aber Vorteile, wenn das übereinstimmt. Es spricht ja nichts dagegen, per Identität einen Account irgendwo zu haben.)
Das (leere) log wird mit dem Befehl (s.u. Repository) git init angelegt und ist (theoretisch) mit dem Befehl git log einsehbar.
Die Einträge, wass, wann geändert wurde, sind sich wiederholende Handlungen, die ich als Kernhandlungen bei der Arbeit mit git betrachte:

Commits oder "Änderungen hinzufügen"

Ein commit ist im Grunde erstmal wirklich nur ein banaler Eintrag im log.
Um einen commit zu machen, teile ich git mit, welche (geänderten, dh. immer: neue/gelöschte/veränderte) Dateien ich im nächsten commit berücksichtigt wissen will. (Ich kann ja mehr geändert haben, als ich in diesem commit berücksichtigen will.)
Nun haben sich die Entwickelnden von git etwas geiles ausgedacht: Anstatt im log jede Änderung anzuzeigen, das wäre unübersichtlich und bei vielen Änderungen kontraproduktiv, gebe ich meinem commit eine aussagekräftige Beschreibung, was mein commit zum vorherigen Zustand ändert, mit.

Erweiterte Konzepte

Aus den obigen Ideen ergeben sich nun ein paar abstraktere Konzepte, die git so wunderbar machen. Als erstes denke ich an das Konzept des

Branches

Ich muss eine kleines Detail zum log hinzufuegen. Wenn ich ein leeres repo anlege, dann wird auch ein leeres log angelegt. Zusätzlich wird aber auch ein branch angelegt zu dem das log dazugehoert. So ein branch hat einen Namen. Früher war der Standardname "master", ändert sich aber zu "main". Das ist konfigurierbar. Je nach konfiguration wird mit git init also auch der branch main angelegt zu dem das log dann gehoert. Bisher sprechen wir also eigentlich vom log des branches main. Normalerweise sind alle branches gleich aber dieser hat eine Besonderheit. Er ist initial, also keine kopie von irgendwo.

Mit freundlicher Hilfe komme ich zu dieser Metapher:
Stellen wir uns vor, wir gehen in den Supermarkt. Unser Einkaufswagen heisst "main" und wir definieren, das wir mit diesem auch zur Kasse später wollen. Der hat so einen Notizblock dran mit einer Tabelle, das log. Spalten: Beschreibung (Wer, Wann und noch ein paar andere Sachen, passieren automatisch, wie auch immer sie das tun).
Wir packen Nudeln, Dosentomaten (wo wir einen Smiley auf die Oberseite malen) und Sahne in den Einkaufswagen und notieren jeweils, wann wir das taten und und beschreiben das Aussagekräftig. (Notieren auch das bemalen mit dem Smiley, wenn es zur Tomatendose kommt)
Ah, da faellt uns auf, die Sahne brauchen wir garnicht. Also wieder raus aus dem Einkaufswagen und auf dem Notizblock notieren, das wir sie wieder weggepackt haben.

Was passiert, wenn wir nun einen neuen branch anlegen, in diesem Bild?
Um es erstmal einfach zu machen, lassen wir den Einkaufswagen stehen und dem passiert auch nichts und bleibt exakt so wie er ist. Aber wir haben plotzlich einen zweiten Einkaufswagen. Mit dem gleichen Inhalt und dem gleichen Verlauf auf dem Notizblock, einen Klon, quasi. Und einem Namen, den wir wählen. Ich glaube, da wir nun alles fuer das Mittagessen haben, machen wir uns gedanken fuer die Feier am Abend und nennen den Einkaufswagen "party-kram".
Wir gehen nun mit dem neuen Wagen los und holen noch Bier und Chips und tragen das jeweils ein und entfernen diesen unsagbar daemlichen Smiley von der Dose und tragen auch diese Änderung ein.
Wir kehren nun zum ersten Einkaufswagen zurueck und ich schlage das Vergleichen des Inhalts der Wägen vor (Ja an mich selbst, aber nur in diesem Falle).
Als erstes fallen auf dem Notizblock und beim Blick in den Wagen die neuen Produkte im zweiten Wagen auf. Wir sind mit dem Bier zufrieden. Aber die Chips waren doch zuviel des guten. Also wird ersteres umgepackt. Dann fällt der fehlende Smiley auf. Wir sind auch hiermit zufrieden und während wir das denken, verschwindet er auf der Dose im ersten Wagen. Nun wird automatisch auf dem Notizblock eine Variante von "mit Einkaufswagen party-kram vereinigt" oder so notiert. Wenn wir den Einkaufswagen "party-kram" nichtmehr brauchen, koennen wir ihn nun entfernen.
Das tolle an git ist, wenn etwas offen entwickelt wird, dann kann Mensch jeden Einkaufswagen an jedem möglichen Zeitpunkt für sich klonen, selber einkaufen gehen und damit reinrausraeumen was man will, und diese Veränderungen an die quelle zurueckvorschlagen.
Ich möchte ein Augenmerk auf das Verhalten beim entfernen der Sahne und des Smileys werfen. Als ich sie entnahm bzw. ihn doof fand und entfernte, habe ich nicht einfach den Eintrag jeweils entfernt, sondern eine Notiz addiert, das ich sie entnahm.
Das hat einen erheblichen Grund. Ich kann zwar wahllos Produkte entfernen und ändern, aber ich sollte nur unter bestimmten umständen die Geschichte auf dem Notizblock ändern, wenn das repo auch nur einmal geteilt ist.
Das zweite Augenmerk moechte ich auf das vergleichen der Inhalte der Wägen legen. Da gibt es mehrere Möglichkeiten, wie sowas in real abläuft, das war nur ein der Metapher (hoffentlich) angemessenes Beispiel.