53 lines
4.0 KiB
Markdown
53 lines
4.0 KiB
Markdown
# Willkommen
|
|
|
|
Ich habe dieses Repository angelegt, damit wir damit ein bisschen spielen koennen. Noch ist es leer aber ich hoffe, wir fuellen es bald.
|
|
|
|
Ich wuerde gerne auf ein bisschemn git-Terminologie eingehen.
|
|
|
|
## Was ist git?
|
|
|
|
git ist eine Software zur "verteilten Versionsverwaltung von Dateien" sagt wikipedia. Genauer bedeutet das, dass ich verschiedene Versionen einer Datei verwalten kann. Und das geht eben auch auf verschiedenen Rechnern.
|
|
|
|
Ein praktisches Beispiel waere folgendes Problem: "Ich moechte mit mehreren Leuten ein Buch schreiben"
|
|
(Damit das passt, gibt es eine Bedingung: Es muss eine Datei sein.)
|
|
(Keine Angst, ich erklaere Fachwoerter noch)
|
|
|
|
Jetzt wuerden wir, herkoemmlich, alle staendig diese Datei austauschen, damit alle auf dem neuesten Stand sind und es wuerden so sachen passieren wie "datei3_jetzt_aber_wirklich.txt" ...
|
|
|
|
Da kommt dann git ins Spiel. In diesem Szenario wuerde ich einen Repository als ultimative Instanz definieren. Z. B. dieses Repository hier "Spielwiese". Das kann man bei github machen, besser gitlab, besser selber hosten. (Es gibt auch Faelle, wo man sowas gar nicht braucht. Z. B. wenn man nur fuer sich etwas versionsverwalten will auf dem eigenen Rechner. Z. B. die Rezeptedatenbank. Oder die Kontakte oder oder ...)
|
|
|
|
Die Leute, die dann an dem Buch mitarbeiten, "forken" sich das Repository damit sie eine Kopie in ihrem eigenen Account haben. Im optimalfall "clonen" sich die Leute das dann von ihren Accounts auf den eigenen Rechner um da dann an den Dateien arbeiten zu koennen.
|
|
|
|
Sinnvoll waere jetzt einen "branch" anzulegen. Ein "branch" ist, quasi, eine Kopie der Daten im gleichen Ordner, der ich einen Namen geben kann. Pro "repository" gibt es immer mindestens einen Branch, der frueher "master" hiess, mittlerweile setzt sich aber "main" durch. Ich lege nun einen "branch" namens "kapitel-2" an und schreibe mein Kapitel in die Datei (Z. B. Buch.txt).
|
|
|
|
Wenn ich dann mit der Aenderung fertig bin, muss ich diese "committen". Das ist ein elementares Ding bei git, daher gehe ich da etwas ausfuehrlicher drauf ein.
|
|
|
|
Eine der wichtigen Dinge, beim verteilten Arbeiten an einem Material, ist die Nachverfolgbarkeit von Aenderungen. Dafuer hat git ein sogenanntes "log" aller Aenderungen. In diesem log stehen auf den ersten Blick aber nicht alle Aenderungen im Detail, sondern nur Zusammenfassungen der Aenderungen.
|
|
|
|
Ich gehe zu unserem Beispiel zurueck und werde noch etwas genauer ab dem Punkt, wo ich denke, dass meine Aenderung am Buch fertig ist.
|
|
Ich nehme ja an, die Datei heisst "Buch.txt" und ich wollte Kapitel 2 hinzufuegen. Nachdem ich damit fertig bin, sage ich git mit einem Befehl, welche Datei in diesen "commit" soll. Das kann von einer Datei bis hin zu allen Dateien sein. Danach gebe ich dann dem commit seine Beschreibung. In diesem Falle wuerde eine commitmessage wie "Kapitel 2 hinzugefuegt" wohl passend sein.
|
|
|
|
Nun muss ich das noch in meinen Account auf dem Server hochladen und von da aus die Aenderung vorschlagen. Wenn die Person, der das Hauptrepository gehoert, mit der Aenderung zufrieden ist, kann sie diese dann in den Hauptzweig des Projektes "mergen".
|
|
|
|
** Keine Angst. Das ist nur ein Ueberblick. Wir werden das nach und nach durchgehen! **
|
|
|
|
[hier noch ein versuch der zusammenfassung](konzept_commit_history.md)
|
|
[hier das git buch](https://git-scm.com/book/de/v2)
|
|
|
|
## Begriffe (todo)
|
|
|
|
- clone: Eine lokale Kopie eines repos.
|
|
- fork: Eine entfernte Kopie eines repos.
|
|
- branch: eine Abspaltung vom vorherigen Arbeitszweig
|
|
- merge: Das Zusammenfuegen der commits von zwei Arbeitszweigen.
|
|
- commit: Zusammenschluss von Aenderungen unter einer Beschreibung.
|
|
- pushen: das hochladen eines branches zum repo, von dem geklont wurde.
|
|
- pull-request (pr): Das Anbieten von Aenderungen am Material.
|
|
- repository (repo): Ein Container wo alles zum Projekt gehoerende drin ist. Kann lokal und remote sein.
|
|
|
|
## Erste Schritte
|
|
|
|
Das erste, was Du jetzt tun kannst ist, dieses repo zu forken. Als Hinweis: Ganz rechts oben sollte "Fork" stehen.
|
|
|
|
|