new: docs/git.md

This commit is contained in:
teldra 2022-04-17 11:04:01 +02:00
parent 1b3e03a04a
commit 4884ad6dcd
1 changed files with 15 additions and 3 deletions

View File

@ -1,6 +1,8 @@
## Git
Wenn wir über git sprechen, gibt es ein paar Fachbegriffe, deren Erklärung wenigstens angerissen werden muss.
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:
@ -14,10 +16,10 @@ Befinde ich mich in einem Ordner, der von git verwaltet werden soll, führe ich
### Logbuch oder "git log"
Im Logbuch, kurz log, wird eingetragen, wer, was, wann geändert hat.
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 log ist mit dem Befehl `git log` einsehbar.
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:
@ -26,3 +28,13 @@ Die Einträge, wass, wann geändert wurde, sind sich wiederholende Handlungen, d
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
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.