/de/drawbacks.txt

https://bitbucket.org/blynn/gitmagic · Plain Text · 183 lines · 138 code · 45 blank · 0 comment · 0 complexity · 4e2c74be78acc8ea2a171719cf34d492 MD5 · raw file

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