/de/drawbacks.txt
Plain Text | 183 lines | 138 code | 45 blank | 0 comment | 0 complexity | 4e2c74be78acc8ea2a171719cf34d492 MD5 | raw file
Possible License(s): GPL-3.0
1== Anhang A: Git's Mängel ==
2
3Ein paar Git-Probleme habe ich bisher unter den Teppich gekehrt. Einige
4lassen sich einfach mit Skripten und 'Hooks' lösen, andere erfordern eine
5Reorganisation oder Neudefinition des gesamten Projekt und für die wenigen
6verbleibenden Beeinträchtigungen kannst Du nur auf eine Lösung warten. Oder
7noch besser, anpacken und mithelfen.
8
9=== SHA1 Schwäche ===
10
11Mit der Zeit entdecken Kryptographen immer mehr Schwächen an SHA1. Schon
12heute wäre für finanzkräftige Unternehmen es technisch machbar,
13Hash-Kollisionen zu finden. In ein paar Jahren hat vielleicht schon ein ganz
14normaler Heim-PC ausreichend Rechenleistung, um ein Git 'Reopsitory'
15unbemerkt zu korrumpieren.
16
17Hoffentlich stellt Git auf eine bessere Hash Funktion um, bevor die
18Forschung SHA1 komplett unnütz macht.
19
20=== Microsoft Windows ===
21
22Git unter Microsoft Windows kann frustrierend sein:
23
24- http://cygwin.com/[Cygwin], eine Linux ähnliche Umgebung für Windows,
25enthält http://cygwin.com/packages/git/[eine Windows Portierung von Git].
26
27- http://code.google.com/p/msysgit/[Git unter MSys] ist eine Alternative,
28die sehr wenig Laufzeitunterstützung erfordert, jedoch bedürfen einige
29Kommandos noch einer Überarbeitung.
30
31=== Dateien ohne Bezug ===
32
33Wenn Dein Projekt sehr groß ist und viele Dateien enthält, die in keinem
34direkten Bezug stehen, trotzdem aber häufig geändert werden, kann Git
35nachteiliger sein als andere Systeme, weil es keine einzelnen Dateien
36überwacht. Git überwacht immer das ganze Projekt, was normalerweise schon
37von Vorteil ist.
38
39Eine Lösung ist es, Dein Projekt in kleinere Stücke aufzuteilen, von denen
40jedes nur die in Beziehung stehenden Dateien enthält. Benutze *git
41submodule* wenn Du trotzdem alles in einem einzigen 'Repository' halten
42willst.
43
44=== Wer macht was? ===
45
46Einige Versionsverwaltungssysteme zwingen Dich explizit, eine Datei auf
47irgendeine Weise für die Bearbeitung zu kennzeichnen. Obwohl es extrem
48lästig ist, wenn es die Kommunikation mit einem zentralen Server erfordert,
49so hat es doch zwei Vorteile:
50
51 1. Unterschiede sind schnell gefunden, weil nur die markierten Dateien
52 untersucht werden müssen.
53
54 2. Jeder kann herausfinden wer sonst gerade an einer Datei arbeitet, indem
55 er beim zentralen Server anfragt, wer die Datei zum Bearbeiten markiert
56 hat.
57
58Mit geeigneten Skripten kannst Du das auch mit Git hinkriegen. Das erfordert
59aber die Mitarbeit der Programmierer, denn sie müssen die Skripte auch
60aufrufen, wenn sie eine Datei bearbeiten.
61
62=== Dateihistorie ===
63
64Da Git die Änderungen über das gesamte Projekt aufzeichnet, erfordert die
65Rekonstruktion des Verlaufs einer einzelnen Datei mehr Aufwand als in
66Versionsverwaltungssystemen, die einzelne Dateien überwachen.
67
68Die Nachteile sind üblicherweise gering und werden gern in Kauf genommen, da
69andere Operationen dafür unglaublich effizient sind. Zum Beispiel ist `git
70checkout` schneller als `cp -a`, und projektweite Unterschiede sind besser zu
71komprimieren als eine Sammlung von Änderungen auf Dateibasis.
72
73=== Der erster Klon ===
74
75Einen Klon zu erstellen ist aufwendiger als in anderen
76Versionsverwaltungssystemen, wenn ein längerer Verlauf existiert.
77
78Der initiale Aufwand lohnt sich aber auf längere Sicht, da die meisten
79zukünftigen Operationen dann schnell und offline erfolgen. Trotzdem gibt es
80Situationen, in denen es besser ist, einen oberflächlichen Klon mit der
81`--depth` Option zu erstellen. Das geht wesentlich schneller, aber der
82resultierende Klon hat nur eingeschränkte Funktionalität.
83
84=== Unbeständige Projekte ===
85
86Git wurde geschrieben um schnell zu sein, im Hinblick auf die Größe der
87Änderungen. Leute machen kleine Änderungen von Version zu Version. Ein
88einzeiliger Bugfix hier, eine neue Funktion da, verbesserte Kommentare und
89so weiter. Aber wenn sich Deine Dateien zwischen aufeinanderfolgenden
90Versionen gravierend ändern, dann wird zwangsläufig mit jedem 'Commit' Dein
91Verlauf um die Größe des gesamten Projekts wachsen.
92
93Es gibt nichts, was irgendein Versionsverwaltungssystem dagegen machen kann,
94aber der Standard Git Anwender leidet mehr darunter, weil normalerweise der
95ganze Verlauf geklont wird.
96
97Die Ursachen für die großen Unterschiede sollten ermittelt
98werden. Vielleicht können Dateiformate geändert werden. Kleinere
99Bearbeitungen sollten auch nur minimale Änderungen an so wenig Dateien wie
100möglich bewirken.
101
102Vielleicht ist eher eine Datenbank oder Sicherungs-/Archivierungslösung
103gesucht, nicht ein Versionsverwaltungssystem. Ein Versionsverwaltungssystem
104zum Beispiel ist eine ungeeignete Lösung um Fotos zu verwalten, die
105periodisch von einer Webcam gemacht werden.
106
107Wenn die Dateien sich tatsächlich konstant verändern, und sie wirklich
108versioniert werden müssen, ist es eine Möglichkeit, Git in zentralisierter
109Form zu verwenden. Jeder kann oberflächliche Klone erstellen, die nur wenig
110oder gar nichts vom Verlauf des Projekts enthalten. Natürlich sind dann
111viele Git Funktionen nicht verfügbar, und Änderungen müssen als 'Patches'
112übermittelt werden. Das funktioniert wahrscheinlich ganz gut, wenn auch
113unklar ist, warum jemand die Versionsgeschichte von wahnsinnig instabilen
114Dateien braucht.
115
116Ein anderes Beispiel ist ein Projekt, das von Firmware abhängig ist, welche
117die Form einer großen Binärdatei annimmt. Der Verlauf der Firmware
118interessiert den Anwender nicht und Änderungen lassen sich schlecht
119komprimieren, so blähen Firmwarerevisionen die Größe des 'Repository'
120unnötig auf.
121
122In diesem Fall sollte der Quellcode der Firmware in einem Git 'Repository'
123gehalten werden und die Binärdatei außerhalb des Projekts. Um das Leben zu
124vereinfachen, könnte jemand ein Skript erstellen, das Git benutzt, um den
125Quellcode zu klonen und 'rsync' oder einen oberflächlichen Klon für die
126Firmware.
127
128=== Globaler Zähler ===
129
130Verschiedene Versionsverwaltungssysteme unterhalten einen Zähler, der mit
131jedem 'Commit' erhöht wird. Git referenziert Änderungen anhand ihres
132SHA1-Hash, was in vielen Fällen besser ist.
133
134Aber einige Leute sind diesen Zähler gewöhnt. Zum Glück ist es einfach,
135Skripte zu schreiben, sodass mit jedem Update das zentrale Git 'Repository'
136einen Zähler erhöht. Vielleicht in Form eines 'Tags', der mit dem SHA1-Hash
137des letzten 'Commit' verknüpft ist.
138
139Jeder Klon könnte einen solchen Zähler bereitstellen, aber der wäre
140vermutlich nutzlos, denn nur der Zähler des zentralen 'Repository' ist für
141alle relevant.
142
143=== Leere Unterverzeichnisse ===
144
145Leere Unterverzeichnisse können nicht überwacht werden. Erstelle eine
146Dummy-Datei, um dieses Problem zu umgehen.
147
148Die aktuelle Implementierung von Git, weniger sein Design, ist
149verantwortlich für diesen Pferdefuß. Mit etwas Glück, wenn Git's Verbreitung
150zunimmt und mehr Anwender nach dieser Funktion verlangen, wird sie
151vielleicht implementiert.
152
153=== Initialer 'Commit' ===
154
155Ein klischeehafter Computerwissenschaftler zählt von 0 statt von 1. Leider,
156bezogen auf 'Commits', hält sich Git nicht an diese Konvention. Viele
157Kommandos sind mürrisch vor dem intialen 'Commit'. Zusätzlich müssen
158verschiedene Grenzfälle speziell behandelt werden, wie der 'Rebase' eines
159'Branch' mit einem abweichenden initialen 'Commit'.
160
161Git würde davon provitieren, einen Null-'Commit' zu definieren: sofort nach
162dem Erstellen eines 'Repository' wird der 'HEAD' auf eine Zeichenfolge von
16320 Null-Bytes gesetzt. Dieser spezielle 'Commit' repräsentiert einen leeren
164'Tree', ohne Eltern, irgendwann vielleicht der Vorfahr aller Git
165'Repositories'.
166
167Würde dann zum Beispiel *git log* ausgeführt, würde der Anwender darüber
168informiert, dass noch keine 'Commits' gemacht wurden, anstelle mit einem
169fatalen Fehler zu beenden. Das gilt stellvertretend für andere
170Anweisungen.
171
172Jeder initiale 'Commit' ist dann stillschweigend ein Abkömmling dieses
173Null-'Commits'.
174
175Leider gibt es noch ein paar Problemfälle. Wenn mehrere 'Branches' mit
176unterschiedlichen initialen 'Commits' zusammengeführt und dann ein 'Rebase'
177gemacht wird, ist ein manuelles Eingreifen erforderlich.
178
179=== Eigenarten der Anwendung ===
180
181Für die 'Commits' A und B, hängt die Bedeutung der Ausdrücke "A..B" und
182"A...B" davon ab, ob eine Anweisung zwei Endpunkte erwartet oder einen
183Bereich. Siehe *git help diff* und *git help rev-parse*.