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](https://de.wikipedia.org/wiki/Git) [Offizielles Git Buch](https://git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung%3F))
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
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.)
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.
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
Dieses Konzept versuche ich über das log zu erklären.
Wenn ich ein leeres repo anlege, dann hat das natürlich keine Abhängigkeiten. Was das bedeutet wird später klar.
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. Ein branch ist ein Name. 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 gehoert. Bisher sprechen wir also eigentlich vom log des branches main. Normalerweise sind alle branches gleich aber dieser hat eine Besonderheit. Er hat keine Abhängigkeit.
