new: docs/git.md

This commit is contained in:
teldra 2022-04-17 10:03:55 +02:00
parent e7d2edb96c
commit 1b3e03a04a
1 changed files with 28 additions and 0 deletions

28
docs/git.md Normal file
View File

@ -0,0 +1,28 @@
## Git
Wenn wir über git sprechen, gibt es ein paar Fachbegriffe, deren Erklärung wenigstens angerissen werden muss.
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 eingetragen, 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.
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.