de/clone.txt

   1 == Rund ums 'Clonen' ==
   2
   3 In älteren Versionsverwaltungssystemen ist 'checkout' die Standardoperation
   4 um Dateien zu bekommen. Du bekommst einen Haufen Dateien eines bestimmten
   5 Sicherungsstands.
   6
   7 In Git und anderen verteilten Versionsverwaltungssystemen ist 'clone' die
   8 Standardaktion. Um Dateien zu bekommen, erstellst du einen 'Clone' des
   9 gesamten 'Repository'. Oder anders gesagt, du spiegelst den zentralen
  10 Server. Alles, was man mit dem zentralen 'Repository' tun kann, kannst du
  11 auch mit deinem 'Clone' tun.
  12
  13 === Computer synchronisieren ===
  14
  15 Es ist akzeptabel, für Datensicherungen und einfaches Synchronisieren, mit
  16 'tarball' Archiven oder *rsync* zu arbeiten. Aber manchmal arbeite ich an
  17 meinem Laptop, dann an meinem Desktop-PC und die beiden haben sich
  18 inzwischen nicht austauschen können.
  19
  20 Erstelle ein Git 'Repository' und 'commite' deine Dateien auf dem einen
  21 Rechner. Dann auf dem anderen:
  22
  23  $ git clone anderer.computer:/pfad/zu/dateien
  24
  25 um eine zweite Kopie der Dateien und des Git 'Repository' zu erstellen. Von
  26 jetzt an wird
  27
  28  $ git commit -a
  29  $ git pull anderer.computer:/pfad/zu/dateien HEAD
  30
  31 den Zustand der Dateien des anderen Computer auf den übertragen, an dem du
  32 gerade arbeitest. Solltest du kürzlich konkurrierende Änderungen an der
  33 selben Datei vorgenommen haben, lässt Git dich das wissen und musst erneut
  34 'commiten' nachdem du die Konflikte aufgelöst hast.
  35
  36 === Klassische Quellcodeverwaltung ===
  37
  38 Erstelle ein Git 'Repository' für deine Dateien:
  39
  40  $ git init
  41  $ git add .
  42  $ git commit -m "Erster Commit"
  43
  44 Auf dem zentralen Server erstelle ein 'bare Repository' in irgendeinem
  45 Ordner:
  46
  47  $ mkdir proj.git
  48  $ cd proj.git
  49  $ git init --bare
  50  $  # einzeilige Variante: GIT_DIR=proj.git git init
  51
  52 Wenn nötig, starte den Git-Dämon:
  53
  54  $ git daemon --detach  # er könnte schon laufen
  55
  56 Für Git Hostingdienste folge den Anweisungen zum Erstellen des zunächst
  57 leeren Git 'Repository'. Normalerweise füllt man ein Formular auf einer
  58 Website aus.
  59
  60 Übertrage ('push') dein Projekt auf den zentralen Server mit:
  61
  62  $ git push git://zentraler.server/pfad/zu/proj.git HEAD
  63
  64 Um die Quellcodes abzurufen gibt ein Entwickler folgendes ein:
  65
  66  $ git clone git://zentraler.server/pfad/zu/proj.git
  67
  68 Nach dem Bearbeiten sichert der Entwickler die Änderungen lokal:
  69
  70  $ git commit -a
  71
  72 Um auf die aktuelle Server-Version zu aktualisieren:
  73
  74  $ git pull
  75
  76 Irgendwelche 'Merge'-Konflikte sollten dann aufgelöst und erneut 'commitet'
  77 werden:
  78
  79  $ git commit -a
  80
  81 Um die lokalen Änderungen in das zentrale 'Repository' zu übertragen:
  82
  83  $ git push
  84
  85 Wenn inzwischen neue Änderungen von anderen Entwicklern beim Hauptserver
  86 eingegangen sind, schlägt dein 'push' fehl. Aktualisiere das lokale
  87 'Repository' erneut mit 'pull', löse eventuell aufgetretene
  88 'Merge'-Konflikte und versuche es nochmal.
  89
  90 === 'Nackte Repositories' ===
  91
  92 Ein nacktes ('bare') 'Repository' wird so genannt, weil es kein
  93 Arbeitsverzeichnis hat. Es enthält nur Dateien, die normalerweise im '.git'
  94 Unterverzeichnis versteckt sind. Mit anderen Worten, es verwaltet die
  95 Geschichte eines Projekts, enthält aber niemals einen Auszug irgendeiner
  96 beliebigen Version.
  97
  98 Ein 'bare Repository' übernimmt die Rolle des Hauptserver in einem
  99 zentralisierten Versionsverwaltungssystem: Das Zuhause deines
 100 Projekts. Entwickler 'clonen' dein Projekt davon und 'pushen' die letzten
 101 offiziellen Änderungen dort hin. Meistens befindet es sich auf einem Server,
 102 der nicht viel tut außer Daten zu verbreiten. Die Entwicklung findet in den
 103 'Clonen' statt, so kann das Heim-'Repository' ohne Arbeitsverzeichnis
 104 auskommen.
 105
 106 Viele Git Befehle funktionieren nicht in 'bare Repositories'. Es sei denn
 107 die `GIT_DIR` Umgebungsvariable wird auf das Arbeitsverzeichnis gesetzt,
 108 oder die `--bare` Option wird übergeben.
 109
 110 === 'Push' oder 'Pull' ===
 111
 112 Warum haben wir den 'push'-Befehl eingeführt, anstatt bei dem vertrauten
 113 'pull'-Befehl zu bleiben? Zuerst, 'pull' funktioniert nicht mit 'bare
 114 Repositories': stattdessen benutze 'fetch', ein Befehl, den wir später
 115 behandeln. Aber auch wenn wir ein normales 'Repository' auf dem zentralen
 116 Server halten würden, wäre das 'pullen' eine mühselige Angelegenheit. Wir
 117 müssten uns zuerst in den Server einloggen und dem 'pull'-Befehl die
 118 Netzwerkadresse des Computer übergeben, von dem aus wir die Änderungen
 119 'pullen', also abholen wollen. Firewalls könnten uns stören und was, wenn
 120 wir gar keine Berechtigung für eine Serverkonsole haben.
 121
 122 Wie auch immer, abgesehen von diesem Fall, raten wir vom 'Pushen' in ein
 123 'Repository' ab. Falls das Ziel nämlich ein Arbeitsverzeichnis hat, können
 124 Verwirrungen entstehen.
 125
 126 Kurzum, während du lernst mit Git umzugehen, 'pushe' nur, wenn das Ziel ein
 127 'bare Repository' ist; andernfalls benutze 'pull'.
 128
 129 === 'Fork' eines Projekts ===
 130
 131 Hast du es satt, wie sich ein Projekt entwickelt? Du denkst, du kannst das
 132 besser? Dann mache folgendes auf deinem Server:
 133
 134  $ git clone git://haupt.server/pfad/zu/dateien
 135
 136 Dann erzähle jedem von deiner 'Fork' des Projekts auf deinem Server.
 137
 138 Zu jedem späteren Zeitpunkt kannst du die Änderungen des Originalprojekts
 139 'mergen' mit:
 140
 141  $ git pull
 142
 143 === Ultimative Datensicherung ===
 144
 145 Du willst zahlreiche, vor Manipulation geschützte, redundante
 146 Datensicherungen an unterschiedlichen Orten? Wenn dein Projekt viele
 147 Entwickler hat, musst du nichts tun! Jeder 'Clone' deines Codes ist eine
 148 vollwertige Datensicherung. Nicht nur des aktuellen Stand, sondern der
 149 gesamten Geschichte. Wird irgendein 'Clone' beschädigt, wird dies dank des
 150 kryptographischen 'Hashing' sofort erkannt, sobald derjenige versucht mit
 151 anderen zu kommunizieren.
 152
 153 Wenn dein Projekt nicht so bekannt ist, finde so viele Server wie du kannst
 154 um dort einen 'Clone' zu platzieren.
 155
 156 Die wirklich Paranoiden sollten immer den letzten 20-Byte SHA1 Hash des
 157 'HEAD' aufschreiben und an einem sicheren Ort aufbewahren. Er muss sicher
 158 sein, aber nicht privat. Zum Beispiel wäre es sicher, ihn in einer Zeitung
 159 zu veröffentlichen, denn es ist schwer für einen Angreifer jede
 160 Zeitungskopie zu manipulieren.
 161
 162 === Multitasking mit Lichtgeschwindigkeit ===
 163
 164 Nehmen wir an du willst parallel an mehreren Funktionen arbeiten. Dann
 165 'commite' dein Projekt und gib ein:
 166
 167  $ git clone . /irgendein/neuer/ordner
 168
 169 Wann immer es sicher ist nutzt Git Verknüpfungen und Dateifreigaben um
 170 diesen 'Clone' zu erzeugen, deshalb wird es blitzartig fertig sein und du
 171 kannst nun an zwei unabhängigen Funktionen arbeiten. Zum Beispiel kannst du
 172 im einen 'Clone' editieren, während der andere übersetzt wird.
 173
 174 Zu jeder Zeit kannst du 'commiten' und die Änderungen vom anderen 'Clone'
 175 mit 'pull' übernehmen.
 176
 177  $ git pull /der/andere/clone HEAD
 178
 179 === Versionsverwaltung im Untergrund ===
 180
 181 Arbeitest du an einem Projekt, das ein anderes Versionsverwaltungssystem
 182 nutzt und vermisst du Git? Dann erstelle ein Git 'Repository' in deinem
 183 Arbeitsverzeichnis:
 184
 185  $ git init
 186  $ git add .
 187  $ git commit -m "Erster Commit"
 188
 189 dann 'Clone' es:
 190
 191  $ git clone . /irgendein/neuer/ordner
 192
 193 Nun gehe in das neue Verzeichnis und arbeite dort mit Git nach
 194 Herzenslust. Irgendwann wirst du dann mit den anderen synchronisieren
 195 wollen, dann gehe in das Originalverzeichnis, aktualisiere mit dem anderen
 196 Versionsverwaltungssystem und gib ein:
 197
 198  $ git add .
 199  $ git commit -m "Synchronisation mit den anderen"
 200
 201 Dann gehe wieder ins neue Verzeichnis und gib ein:
 202
 203  $ git commit -a -m "Beschreibung der Änderungen"
 204  $ git pull
 205
 206 Die Vorgehensweise, wie du deine Änderungen den anderen übergibst, hängt vom
 207 anderen Versionsverwaltungssystem ab. Das neue Verzeichnis enthält die
 208 Dateien mit deinen Änderungen. Führe die Anweisungen des anderen
 209 Versionsverwaltungssystems aus, die nötig sind um die Dateien ins zentrale
 210 'Repository' zu übertragen.
 211
 212 Subversion, vielleicht das beste zentralisierte Versionsverwaltungssystem,
 213 wird von unzähligen Projekten benutzt. Der *git svn*-Befehl automatisiert
 214 den zuvor genannten Ablauf für Subversion 'Repositories' und kann auch
 215 benutzt werden um
 216 http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[ein
 217 Git Projekt in ein Subversion 'Repository' zu exportieren].
 218
 219 === Mercurial ===
 220
 221 Mercurial ist ein ähnliches Versionsverwaltungssystem, das fast nahtlos mit
 222 Git zusammenarbeiten kann. Mit der `hg-git`-Erweiterung kann ein Benutzer
 223 von Mercurial verlustfrei in ein Git 'Repository' 'pushen' und daraus
 224 'pullen'.
 225
 226 Beschaffe dir die `hg-git`-Erweiterung mit Git:
 227
 228  $ git clone git://github.com/schacon/hg-git.git
 229
 230 oder Mercurial:
 231
 232  $ hg clone http://bitbucket.org/durin42/hg-git/
 233
 234 Leider kenne ich keine solche Erweiterung für Git. Aus diesem Grund plädiere
 235 ich für Git statt Mercurial für ein zentrales 'Repository', auch wenn man
 236 Mercurial bevorzugt. Bei einem Mercurial Projekt gibt es gewöhnlich immer
 237 einen Freiwilligen, der parallel dazu ein Git 'Repository' für die Git
 238 Anwender unterhält, wogegen, Dank der `hg-git`-Erweiterung, ein Git Projekt
 239 automatisch die Benutzer von Mercurial mit einbezieht.
 240
 241 Die Erweiterung kann auch ein Mercurial 'Repository' in ein Git 'Repository'
 242 umwandeln, indem man in ein leeres 'Repository' 'pushed'. Einfacher geht das
 243 mit dem `hg-fast-export.sh` Skript, welches es hier gibt:
 244
 245  $ git clone git://repo.or.cz/fast-export.git
 246
 247 Zum Konvertieren gib in einem leeren Verzeichnis ein:
 248
 249  $ git init
 250  $ hg-fast-export.sh -r /hg/repo
 251
 252 nachdem du das Skript zu deinem `$PATH` hinzugefügt hast.
 253
 254 === Bazaar ===
 255
 256 Wir erwähnen auch kurz Bazaar, weil es nach Git und Mercurial das
 257 bekannteste freie verteilte Versionsverwaltungssystem ist.
 258
 259 Bazaar hat den Vorteil des Rückblicks, da es relativ jung ist; seine
 260 Entwickler konnten aus Fehlern der Vergangenheit lernen und kleine
 261 historische Unwegbarkeiten umgehen. Außerdem waren sich die Entwickler der
 262 Popularität und Interoperabilität mit anderen Versionsverwaltungssystemen
 263 bewusst.
 264
 265 Eine `bzr-git`-Erweiterung lässt Anwender von Bazaar einigermaßen mit Git
 266 'Repositories' arbeiten. Das `tailor` Programm konvertiert Bazaar
 267 'Repositories' zu Git 'Repositories' und kann das forlaufend tun, während
 268 `bzr-fast-export` für einmalige Konvertierungen besser geeignet ist.
 269
 270 === Warum ich Git benutze ===
 271
 272 Ich habe ursprünglich Git gewählt, weil ich gehört habe, dass es die
 273 unvorstellbar unüberschaubaren Linux Kernel Quellcodes verwalten kann. Ich
 274 hatte noch keinen Grund zu wechseln. Git hat mir bewundernswert gedient und
 275 hat mich bis jetzt noch nie im Stich gelassen. Da ich in erster Linie unter
 276 Linux arbeite, sind Probleme anderer Plattformen bedeutungslos.
 277
 278 Ich bevorzuge auch C-Programme und 'bash'-Skripte gegenüber Anwendungen wie
 279 zum Beispiel Python Skripts: Es gibt weniger Abhängigkeiten und ich bin
 280 süchtig nach schellen Ausführungszeiten.
 281
 282 Ich dachte darüber nach, wie Git verbessert werden könnte, ging sogar so
 283 weit, dass ich meine eigene Git-Ähnliche Anwendung schrieb, allerdings nur
 284 als akademische Übungen. Hätte ich mein Projekt fertig gestellt, wäre ich
 285 trotzdem bei Git geblieben, denn die Verbesserungen wären zu gering gewesen
 286 um den Einsatz eines Eigenbrödler-Systems zu rechtfertigen.
 287
 288 Natürlich können deine Bedürfnisse und Wünsche ganz anders sein und
 289 vielleicht bist du mit einem anderen System besser dran. Wie auch immer, mit
 290 Git kannst du nicht viel falsch machen.