de/intro.txt

   1 == Einleitung ==
   2
   3 Ich benutze eine Analogie um in die Versionsverwaltung einzuführen. Für eine
   4 vernünftigere Erklärung siehe
   5 http://de.wikipedia.org/wiki/Versionsverwaltung[den Wikipedia Artikel zur
   6 Versionsverwaltung].
   7
   8 === Arbeit ist Spiel ===
   9
  10 Ich spiele Computerspiele schon fast mein ganzes Leben. Im Gegensatz dazu
  11 habe ich erst als Erwachsener damit begonnen Versionsverwaltungssysteme zu
  12 benutzen. Ich vermute, dass ich damit nicht alleine bin und der Vergleich
  13 hilft vielleicht dabei die Konzepte einfacher zu erklären und zu verstehen.
  14
  15 Stelle dir das Bearbeiten deines Codes oder deiner Dokumente wie ein
  16 Computerspiel vor. Wenn du gut voran gekommen bist, willst du das Erreichte
  17 sichern. Um das zu tun, klickst du auf auf Speichern in deinem vertrauten
  18 Editor.
  19
  20 Aber, das überschreibt die vorherige Version. Das ist wie bei den Spielen
  21 der alten Schule, die nur Speicherplatz für eine Sicherung hatten:
  22 sicherlich konntest du speichern, aber du konntest nie zu einem älteren
  23 Stand zurück. Das war eine Schande, denn vielleicht war deine vorherige
  24 Sicherung an einer außergewöhnlich spannenden Stelle des Spiels, zu der du
  25 später gerne noch einmal zurückkehren möchtest. Oder noch schlimmer, deine
  26 aktuelle Sicherung ist in einem nicht lösbaren Stand, dann musst du von ganz
  27 vorne beginnen.
  28
  29 === Versionsverwaltung ===
  30
  31 Beim Editieren kannst du deine Datei durch 'Speichern unter ...' mit einem
  32 neuen Namen abspeichern oder du kopierst sie vor dem Speichern irgendwo hin
  33 um die alte Version zu erhalten. Außerdem kannst du sie komprimieren um
  34 Speicherplatz zu sparen. Das ist eine primitive und mühselige Form der
  35 Versionsverwaltung. Computerspiele machten das lange Zeit so, viele von
  36 ihnen hatten automatisch erstellte Sicherungspunkte mit Zeitstempel.
  37
  38 Jetzt lass uns das Problem etwas komplizierter machen. Sagen wir, du hast
  39 einen Haufen Dateien, die zusammen gehören, z.B. Quellcodes für ein Projekt
  40 oder Dateien einer Website. Wenn du nun eine alte Version erhalten willst,
  41 musst du den ganzen Ordner archivieren. Viele Versionen auf diese Art zu
  42 archivieren ist mühselig und kann sehr schnell teuer werden.
  43
  44 Bei einigen Computerspielen bestand ein gesicherter Stand wirklich aus einem
  45 Ordner voller Dateien. Diese Spiele versteckten die Details vor dem Spieler
  46 und präsentierten eine bequeme Oberfläche um verschiedene Versionen des
  47 Ordners zu verwalten.
  48
  49 Versionsverwaltungen sind nicht anders. Sie alle haben bequeme
  50 Schnittstellen um Ordner voller Dateien zu verwalten. Du kannst den Zustand
  51 des Ordners sichern so oft du willst und du kannst später jeden
  52 Sicherungspunkt wieder herstellen. Im Gegensatz zu den meisten
  53 Computerspielen sind sie aber in der Regel dafür ausgelegt sparsam mit dem
  54 Speicherplatz umzugehen. Normalerweise ändern sich immer nur wenige Dateien
  55 zwischen zwei Versionen und die Änderungen selbst sind oft nicht groß. Die
  56 Platzersparnis beruht auf dem Speichern der Unterschiede an Stelle einer
  57 Kopie der ganzen Datei.
  58
  59 === Verteilte Kontrolle ===
  60
  61 Nun stell dir ein ganz kompliziertes Computerspiel vor. So schwierig zu
  62 lösen, dass viele erfahrene Spieler auf der ganzen Welt beschließen sich
  63 zusammen zu tun und ihre gespeicherten Spielstände auszutauschen um das
  64 Spiel zu beenden. 'Speedruns' sind Beispiele aus dem echten Leben: Spieler,
  65 die sich in unterschiedlichen Spielebenen des selben Spiels spezialisiert
  66 haben, arbeiten zusammen um erstaunliche Ergebnisse zu erzielen.
  67
  68 Wie würdest du ein System erstellen, bei dem jeder auf einfache Weise die
  69 Sicherungen der anderen bekommt? Und eigene Sicherungen bereitstellt?
  70
  71 Früher nutzte jedes Projekt eine zentralisierte Versionsverwaltung. Irgendwo
  72 speicherte ein Server alle gespeicherten Spiele, sonst niemand. Jeder
  73 Spieler hatte nur ein paar gespeicherte Spiele auf seinem Rechner. Wenn ein
  74 Spieler einen Fortschritt machen wollte, musste er den aktuellsten Stand vom
  75 Hauptserver herunterladen, eine Weile spielen, sichern und den Stand dann
  76 wieder auf den Server laden, damit irgendjemand ihn nutzen kann.
  77
  78 Was, wenn ein Spieler aus irgendeinem Grund einen alten Spielstand will?
  79 Vielleicht ist der aktuell gesicherte Spielstand nicht mehr lösbar, weil
  80 jemand in der dritten Ebene vergessen hat ein Objekt aufzunehmen und sie
  81 versuchen den letzten Spielstand zu finden, ab dem das Spiel wieder lösbar
  82 ist. Oder sie wollen zwei Spielstände vergleichen, um festzustellen wie viel
  83 ein Spieler geleistet hat.
  84
  85 Es gibt viele Gründe warum man einen älteren Stand sehen will, aber das
  86 Ergebnis ist das selbe. Man muss vom Hauptserver das alte gespeicherte Spiel
  87 anfordern. Je mehr gespeicherte Spiele benötigt werden, desto mehr
  88 Kommunikation ist erforderlich.
  89
  90 Die neue Generation der Versionsverwaltungssysteme, zu denen Git gehört,
  91 werden verteilte Systeme genannt und können als eine Verallgemeinerung der
  92 zentralisierten Systeme verstanden werden. Wenn Spieler vom Hauptserver
  93 herunterladen, erhalten sie jedes gespeichertes Spiel, nicht nur das zuletzt
  94 gespeicherte. Es ist als ob der Hauptserver gespiegelt wird.
  95
  96 Dieses erste 'Cloning' kann teuer sein, vor allem, wenn eine lange
  97 Geschichte existiert, aber auf Dauer wird es sich lohnen. Ein unmittelbarer
  98 Vorteil ist, wenn aus irgendeinem Grund ein älterer Stand benötigt wird, ist
  99 keine Kommunikation mit dem Hauptserver notwendig.
 100
 101 === Ein dummer Aberglaube ===
 102
 103 Ein weit verbreitetes Missverständnis ist, dass verteilte System ungeeignet
 104 sind für Projekte, die ein offizielles zentrales 'Repository'
 105 benötigen. Nichts könnte weiter von der Wahrheit entfernt sein. Jemanden zu
 106 fotografieren stiehlt nicht dessen Seele. Genauso wenig setzt das 'Clonen'
 107 des zentralen 'Repository' dessen Bedeutung herab.
 108
 109 Eine gute erste Annäherung ist, dass alles was eine zentralisierte
 110 Versionsverwaltung kann, ein gut durchdachtes verteiltes System besser
 111 kann. Netzwerkressourcen sind einfach teurer als lokale Ressourcen. Auch
 112 wenn wir später Nachteile beim verteilten Ansatz sehen werden, ist man mit
 113 dieser Faustregel weniger anfällig für falsche Vergleiche.
 114
 115 Ein kleines Projekt mag nur einen Bruchteil der Möglichkeiten benötigen, die
 116 so ein System bietet. Aber deshalb ein einfacheres, schlecht erweiterbares
 117 System zu benutzen, ist wie römische Ziffern zum Rechnen mit kleinen Zahlen
 118 zu verwenden.
 119
 120 Außerdem könnte dein Projekt weit über die ursprünglichen Erwartungen
 121 hinauswachsen. Git von Anfang an zu benutzen, ist wie ein Schweizer
 122 Taschenmesser mit sich zu tragen, auch wenn damit meistens nur Flaschen
 123 geöffnet werden. Eines Tages brauchst du vielleicht dringend einen
 124 Schraubendreher, dann bist du froh mehr als nur einen einfachen
 125 Flaschenöffner bei dir zu haben.
 126
 127 === 'Merge' Konflikte ===
 128
 129 Für diesen Punkt ist unsere Computerspielanalogie ungeeignet. Stattdessen
 130 stellen wir uns wieder vor, wir editieren ein Dokument.
 131
 132 Stell dir vor, Alice fügt eine Zeile am Dateianfang hinzu und Bob eine am
 133 Dateiende. Beide laden ihre Änderungen hoch. Die meisten Systeme wählen
 134 automatisch eine vernünftige Vorgehensweise: akzeptiere beide Änderungen und
 135 füge sie zusammen, damit fließen beide Änderungen in das Dokument mit ein.
 136
 137 Nun stell dir vor beide, Alice und Bob, machen Änderungen in der selben
 138 Zeile. Dann ist es unmöglich ohne menschlichen Eingriff fortzufahren. Die
 139 zweite Person, welche die Datei hoch lädt, wird über einen _'Merge'
 140 Konflikt_ informiert und muss entscheiden, welche Änderung übernommen wird
 141 oder die ganze Zeile überarbeiten.
 142
 143 Es können noch weitaus kompliziertere Situationen
 144 entstehen. Versionsverwaltungssysteme behandeln die einfacheren Fälle selbst
 145 und überlassen die schwierigen uns Menschen. Üblicherweise ist deren
 146 Verhalten einstellbar.