Glossar (GIT)

Aus Siduction Wiki DE
Wechseln zu: Navigation, Suche

GIT-Tutorial: Übersicht

Vorbemerkung

Hier werden Begriffe erläutert, die bei Versionskontrollsystemen benutzt werden. Sie sind also nur dann GIT-spezifisch, wenn dies explizit erwähnt wird.

VCS

Kürzel für Version Control System. Das ist ein System, das die Historie von Inhalten verwaltet. Damit ist es möglich, den Entwicklungsverlauf eins Projekts zu rekonstruieren, Unterschiede zu ermitteln, verschiedene Entwicklungszweige zu pflegen und diese (auch teilweise) abzugleichen.

Repository

Ein Repository ist eine Datenbank, die die Informationen über die Historie aller Dateien eines oder mehrerer Projekts enthält. GIT verwendet dazu das Verzeichnis .git, das im Arbeitsverzeichnis des Projekts liegt.

Serverbasierte VCSe bieten eine Untergliederung (Einlagerung viele Projekte) an, bei CVS z.B. "Module" genannt. Bei GIT, wie bei den meisten verteilten VCSen, hat jedes Projekt sein eigenes Repository.

Verteilt versus serverbasiert

Ein serverbasiertes VCS besitzt genau ein Repository. Meist werden Teilinformationen aus dem Repository von den Clients auch lokal gespeichert, damit bestimmte Funktionen auch ohne Verbindung zum Server zur Verfügung stehen. Der volle Funktionsumfang ist aber nur bei Verbindung zum Server möglich.

Bei verteilten VCSen ist eine Nutzung netzunabhänging. Um eine gemeinsame Entwicklung von mehreren Akteuren zu ermöglichen, bieten diese System ein Clonen (Kopieren) von Repositories und den Abgleich (Übernahme von Änderungen in ein anderes System) an.

SHA1-Hash

Spezialität von GIT: Alle Objekte werden durch einen kryptographischen "Fußabdruck" identifiziert: Der Inhalt des Objekts wird auf einen Wert abgebildet, bei SHA1 ist das ein 20-Byte-Wert und wird mit 40 Hexziffern dargestellt. Damit sind 256**20 = 1.4 * 10E48 Werte möglich. Der SHA-1 ist so ausgelegt, dass eine Kollision (verschiedene Inhalte ergeben einen gleichen Hashwert) extrem unwahrscheinlich ist.

Zur Veranschaulichung des Wertebereichs: Wenn von 10 Milliarden Menschen jeder 10 Milliarden Maschinen hätte, die je Sekunde 10 Milliarden Schlüssel berechnen, dauert es immer noch 46 Jahre, bis alle Schlüssel berechnet sind.

Clonen

Duplizierung eines Repositories. Das kopierte Repository hat die gleichen Inhalte/Historien wie das Orginal. Bei GIT wird die Konfiguration nicht mitkopiert, z.B. Hooks.

Commit

Die Änderungen der Quelldateien finden immer im Arbeitsverzeichnis statt. Durch den Commit-Vorgang werden die Änderungen ins Repository übernommen. Dabei sollte immer eine Commit-Meldung mitgegeben werden, die die Änderung kurz beschreibt. Diese Meldung kann dann im Log angeschaut werden.

  • Commits haben immer eine eindeutige ID, den SHA1-Hash.
  • Der letzte Commit jedes Branches kann auch unter der Bezeichnung HEAD angesprochen werden.
  • Der vorletzte Commit heißt auch HEAD~1, der drittletzte HEAD~2 usw.

Branch

Ein Branch ist ein Entwicklungsast eines Repositories und kann parallel zu beliebig vielen andern Branches weiterentwickelt werden. Jedes VCS bietet Möglichkeiten, Änderungen aus einem Branch in einen anderen zu übernehmen.

GIT kennt vordefinierte Branchnamen:

  • master: Diesen Branch gibt es immer, er muss also nicht (und kann nicht) angelegt werden.
  • origin/master: Der Branch, der mit dem letzten "git fetch" (oder git pull) vom "Vater-Repository" geholt wurde.

Diese vordefinierten Namen sind nur Konvention. Es stiftet aber nur Verwirrung, diese Namen selbst zu definieren!

Tag

Ein Tag ist ein Name für einen Zustand aller Dateien eines Branches zum Zeitpunkt der Vergabe des Tags. GIT erlaubt es, dem Tag eine Log-Meldung mitzugeben.

GIT kennt leichtgewichtige Tags: Diese sind nur in dem Repository sichtbar, in dem sie erzeugt wurden.

Die kommentierten Tags ("anotated tags") werden mit der Option -a, -s oder -u <key> erzeugt und beim Export mit push weitergereicht.

Hinweis: -s bzw. -u sorgen für eine Signierung des Tags.

Mergen und Merge-Konflikt

Änderungen von einem anderen Branch übernehmen. Das Ergebnis ist ein neuer Zustand.

Jedes VCS versucht, Mergen möglichst automatisiert zu erledigen. Warum das nicht immer geht, hier an einem kleinen Beispiel:

  • Zustand 1: A B
  • Zustand 2a: A X B
  • Zustand 2b: A Y B

Zustand 2a und Zustand 2b sind jeweils aus Zustand 1 entstanden. Ein VCS erkennt, dass zwischen A und B jeweils ein anderer Wert (X bzw. Y) eingefügt wurde. Es kann jedoch nicht wissen, welches der denkbaren Ergebnisse eines Zusammenführens korrekt ist:

  • A X B
  • A Y B
  • A X Y B
  • A Y X B
  • A Z B (wobei Z weder X noch Y ist)

Diese Situation wird ein Konflikt genannt.