de/branch.txt

   1 == 'Branch'-Magie ==
   2
   3 Unverzügliches 'Branchen' und 'Mergen' sind die hervorstechenden
   4 Eigenschaften von Git.
   5
   6 *Problem*: Externe Faktoren zwingen zum Wechsel des Kontext. Ein schwerwiegender Fehler in der veröffentlichten Version tritt ohne Vorwarnung auf. Die Frist für ein bestimmtes Leistungsmerkmal rückt näher. Ein Entwickler, dessen Unterstützung für eine Schlüsselstelle im Projekt wichtig ist, verlässt das Team. In allen Fällen musst du alles stehen und liegen lassen und dich auf eine komplett andere Aufgabe konzentrieren.
   7
   8 Den Gedankengang zu unterbrechen ist schlecht für die Produktivität und je
   9 komplizierter der Kontextwechsel ist, desto größer ist der Verlust. Mit
  10 zentraler Versionsverwaltung müssen wir eine neue Arbeitskopie vom Server
  11 herunterladen. Bei verteilen Systemen ist das viel besser, da wir die
  12 benötigt Version lokal 'clonen' können.
  13
  14 Doch das 'Clonen' bringt das Kopieren des gesamten Arbeitsverzeichnis wie
  15 auch die ganze Geschichte bis zum angegebenen Punkt mit sich. Auch wenn Git
  16 die Kosten durch Dateifreigaben und Verknüpfungen reduziert, müssen doch die
  17 gesamten  Projektdateien im neuen Arbeitsverzeichnis erstellt werden.
  18
  19 *Lösung*: Git hat ein besseres Werkzeug für diese Situationen, die wesentlich schneller und platzsparender als 'clonen' ist: *git branch*.
  20
  21 Mit diesem Zauberwort verwandeln sich die Dateien in deinem
  22 Arbeitsverzeichnis plötzlich von einer Version in eine andere. Diese
  23 Verwandlung kann mehr als nur in der Geschichte vor und zurück gehen. Deine
  24 Dateien können sich verwandeln, vom aktuellsten Stand, zur experimentellen
  25 Version, zum neusten Entwicklungsstand, zur Version deines Freundes und so
  26 weiter.
  27
  28 === Die Chef-Taste ===
  29
  30 Hast du schon einmal ein Spiel gespielt, wo beim Drücken einer Taste (``der
  31 Chef-Taste''), der Monitor sofort ein Tabellenblatt oder etwas anderes
  32 angezeigt hat? Dass, wenn der Chef ins Büro spaziert, während du das Spiel
  33 spielst, du es schnell verstecken kannst?
  34
  35 In irgendeinem Verzeichnis:
  36
  37  $ echo "Ich bin klüger als mein Chef" > meinedatei.txt
  38  $ git init
  39  $ git add .
  40  $ git commit -m "Erster Stand"
  41
  42 Wir haben ein Git 'Repository' erstellt, das eine Textdatei mit einer
  43 bestimmten Nachricht enthält. Nun gib ein:
  44
  45  $ git checkout -b chef  # scheinbar hat sich danach nichts geändert
  46  $ echo "Mein Chef ist klüger als ich" > meinedatei.txt
  47  $ git commit -a -m "Ein anderer Stand"
  48
  49 Es sieht aus als hätten wir unsere Datei überschrieben und 'commitet'. Aber
  50 es ist eine Illusion. Tippe:
  51
  52  $ git checkout master  # wechsle zur Originalversion der Datei
  53
  54 und Simsalabim! Die Textdatei ist wiederhergestellt. Und wenn der Chef in
  55 diesem Verzeichnis herumschnüffelt, tippe:
  56
  57  $ git checkout chef  # wechsle zur Version die der Chef ruhig sehen kann
  58
  59 Du kannst zwischen den beiden Versionen wechseln, so oft du willst und du
  60 kannst unabhängig voneinander in jeder Version Änderungen 'commiten'
  61
  62 === Schmutzarbeit ===
  63
  64 [[branch]] Sagen wir, du arbeitest an einer Funktion und du musst, warum
  65 auch immer, drei Versionen zurückgehen um ein paar print Anweisungen
  66 einzufügen, damit du siehst, wie etwas funktioniert. Dann:
  67
  68  $ git commit -a
  69  $ git checkout HEAD~3
  70
  71 Nun kannst du überall wild temporären Code hinzufügen. Du kannst diese
  72 Änderungen sogar 'commiten'. Wenn du fertig bist,
  73
  74  $ git checkout master
  75
  76 um zur ursprünglichen Arbeit zurückzukehren. Beachte, dass alle Änderungen,
  77 die nicht 'commitet' sind übernommen werden.
  78
  79 Was, wenn du am Ende die temporären Änderungen sichern willst? Einfach:
  80
  81  $ git checkout -b schmutzig
  82
  83 und 'commite' bevor du auf den 'Master Branch' zurückschaltest. Wann immer
  84 du zu deiner Schmutzarbeit zurückkehren willst, tippe einfach:
  85
  86  $ git checkout schnmutzig
  87
  88 Wir sind mit dieser Anweisung schon in einem früheren Kapitel in Berührung
  89 gekommen, als wir das Laden alter Stände besprochen haben. Nun können wir
  90 die ganze Geschichte erzählen: Die Dateien ändern sich zu dem angeforderten
  91 Stand, aber wir müssen den 'Master Branch' verlassen. Jeder 'Commit' ab
  92 jetzt führt deine Dateien auf einen anderen Weg, dem wir später noch einen
  93 Namen geben können.
  94
  95 Mit anderen Worten, nach dem Abrufen eines alten Stands versetzt dich Git
  96 automatisch in einen neuen, unbenannten 'Branch', der mit *git checkout -b*
  97 benannt und gesichert werden kann.
  98
  99 === Schnelle Fehlerbehebung ===
 100
 101 Du steckst mitten in der Arbeit, als es heißt alles fallen zu lassen um
 102 einen neu entdeckten Fehler in 'Commit' `1b6d...` zu beheben:
 103
 104  $ git commit -a
 105  $ git checkout -b fixes 1b6d
 106
 107 Dann, wenn du den Fehler behoben hast:
 108
 109  $ git commit -a -m "Fehler behoben"
 110  $ git push  # ins zentrale 'Repository'
 111  $ git checkout master
 112
 113 und fahre mit deiner ursprünglichen Arbeit fort.
 114
 115 Du kannst die Fehlerbehebung, die du gerade gemacht hast, auch
 116 'mergen'. Entweder durch:
 117
 118  $ git merge fixes
 119
 120 oder:
 121
 122  $ git pull
 123
 124 da du die Fehlerbehebung schon ins zentrale 'Repository' ge'pushed' hast.
 125
 126 === 'Mergen' ===
 127
 128 Mit einigen Versionsverwaltungssystemen ist das Erstellen eines 'Branch'
 129 einfach, aber das Zusammenfügen ('Mergen') ist schwierig. Mit Git ist
 130 'Mergen' so einfach, dass du gar nicht merkst, wenn es passiert.
 131
 132 Tatsächlich sind wir dem 'Mergen' schon lange begegnet. Die *pull* Anweisung
 133 holt ('fetch') eigentlich die 'Commits' und verschmilzt ('merged') diese
 134 dann mit dem aktuellen 'Branch'. Wenn du keine lokalen Änderungen hast, dann
 135 ist 'merge' eine 'schnelle Weiterleitung', ein Ausnahmefall, ähnlich dem
 136 Abrufen der letzten Version eines zentralen Versionsverwaltungssystems. Wenn
 137 du aber Änderungen hast, wird Git diese automatisch 'mergen' und dir
 138 Konflikte melden.
 139
 140 Normalerweise hat ein 'Commit' genau einen Eltern-'Commit', nämlich den
 141 vorhergehenden 'Commit'. Das 'Mergen' mehrerer 'Branches' erzeugt einen
 142 'Commit' mit mindestens zwei Eltern. Das wirft die Frage auf: Welchen
 143 'Commit' referenziert `HEAD~10` tatsächlich? Ein 'Commit' kann mehrere
 144 Eltern haben, welchem folgen wir also?
 145
 146 Es stellt sich heraus, dass diese Notation immer den ersten Elternteil
 147 wählt. Dies ist erstrebenswert, denn der aktuelle 'Branch' wird zum ersten
 148 Elternteil während eines 'Merge'; häufig bist du nur von Änderungen
 149 betroffen, die du im aktuellen 'Branch' gemacht hast, als von den Änderungen
 150 die von anderen 'Branches' eingebracht wurden.
 151
 152 Du kannst einen bestimmten Elternteil mit einem Caret-Zeichen
 153 referenzieren. Um zum Beispiel die Logs vom zweiten Elternteil anzuzeigen:
 154
 155  $ git log HEAD^2
 156
 157 Du kannst die Nummer für den ersten Elternteil weglassen. Um zum Beispiel
 158 die Unterschiede zum ersten Elternteil anzuzeigen:
 159
 160  $ git diff HEAD^
 161
 162 Du kannst diese Notation mit anderen Typen kombinieren. Zum Beispiel:
 163
 164  $ git checkout 1b6d^^2~10 -b uralt
 165
 166 beginnt einen neuen 'Branch' ``uralt'', welcher den Stand 10 'Commits'
 167 zurück vom zweiten Elternteil des ersten Elternteil des 'Commits', dessen
 168 Hashwert mit 1b6d beginnt.
 169
 170 === Kontinuierlicher Arbeitsfluss ===
 171
 172 In Herstellungsprozessen muss der zweiter Schritt eines Plans oft auf die
 173 Fertigstellung des ersten Schritt warten. Ein Auto, das repariert werden
 174 soll, steht unbenutzt in der Garage bis ein Ersatzteil geliefert wird. Ein
 175 Prototyp muss warten, bis ein Baustein fabriziert wurde, bevor die
 176 Konstruktion fortgesetzt werden kann.
 177
 178 Bei Softwareprojekten kann das ähnlich sein. Der zweite Teil eines
 179 Leistungsmerkmals muss warten, bis der erste Teil veröffentlicht und
 180 getestet wurde. Einige Projekte erfordern, dass dein Code überprüft werden
 181 muss bevor er akzeptiert wird, du musst also warten, bis der erste Teil
 182 geprüft wurde, bevor du mit dem zweiten Teil anfangen kannst.
 183
 184 Dank des schmerzlosen 'Branchen' und 'Mergen' können wir die Regeln beugen
 185 und am Teil II arbeiten, bevor Teil I offiziell freigegeben
 186 wurde. Angenommen du hast Teil I 'commitet' und zur Prüfung
 187 eingereicht. Sagen wir du bist im `master` 'Branch'. Dann 'branche' zu Teil
 188 II:
 189
 190  $ git checkout -b teil2
 191
 192 Du arbeitest also an Teil II und 'commitest' deine Änderungen
 193 regelmäßig. Irren ist menschlich und so kann es vorkommen, dass du zurück zu
 194 Teil I willst um einen Fehler zu beheben. Wenn du Glück hast oder sehr gut
 195 bist, kannst du die nächsten Zeilen überspringen.
 196
 197  $ git checkout master  # Gehe zurück zu Teil I.
 198  $ fix_problem
 199  $ git commit -a        # 'Commite' die Lösung.
 200  $ git checkout teil2   # Gehe zurück zu Teil II.
 201  $ git merge master     # 'Merge' die Lösung.
 202
 203 Schließlich, Teil I ist zugelassen:
 204
 205  $ git checkout master  # Gehe zurück zu Teil I.
 206  $ submit files         # Veröffentliche deine Dateien!
 207  $ git merge teil2      # 'Merge' in Teil II.
 208  $ git branch -d teil2
 209
 210 Nun bist du wieder im `master` 'Branch', mit Teil II im Arbeitsverzeichnis.
 211
 212 Es ist einfach, diesen Trick auf eine beliebige Anzahl von Teilen zu
 213 erweitern. Es ist genauso einfach rückwirkend zu 'branchen': angenommen, du
 214 merkst zu spät, dass vor sieben 'Commits' ein 'Branch' erforderlich gewesen
 215 wäre. Dann tippe:
 216
 217  $ git branch -m master teil2
 218  $  # Umbenennen des 'Branch' "master" zu "teil2".
 219  $ git checkout HEAD~7 -b master
 220
 221 Der `master` 'Branch' enthält nun nur den Teil I und der `teil2` 'Branch'
 222 enthält den Rest.
 223
 224 === Mischmasch Reorganisieren ===
 225
 226 Vielleicht magst du es, alle Aspekte eines Projekts im selben 'Branch'
 227 abzuarbeiten. Du willst deine laufenden Arbeiten für dich behalten und
 228 andere sollen deine 'Commits' nur sehen, wenn du sie hübsch organisiert
 229 hast. Beginne ein paar 'Branches':
 230
 231   $ git checkout -b bereinigt
 232   $ git checkout -b mischmasch
 233
 234 Fahre fort alles zu bearbeiten: Behebe Fehler, füge Funktionen hinzu,
 235 erstelle temporären Code und so weiter und 'commite' deine Änderungen
 236 oft. Dann:
 237
 238   $ git checkout bereinigt
 239   $ git cherry-pick mischmasch^^
 240
 241 wendet den Urahn des obersten 'Commit' des ``mischmasch'' 'Branch' auf den
 242 ``bereinigt'' 'Branch' an. Durch das Herauspicken der Rosinen kannst du
 243 einen 'Branch' konstruieren, der nur endgültigen Code enthält und
 244 zusammengehörige 'Commits' gruppiert hat.
 245
 246 === 'Branches' verwalten ===
 247
 248 Ein Liste aller 'Branches' bekommst du mit:
 249
 250  $ git branch
 251
 252 Standardmäßig beginnst du in einem 'Branch' namens ``master''. Einige
 253 plädieren dafür, den ``master'' 'Branch' unangetastet zu lassen und für
 254 seine Arbeit einen neuen 'Branch' anzulegen.
 255
 256 Die *-d* und *-m* Optionen erlauben dir 'Branches' zu löschen und zu
 257 verschieben (umzubenennen). Siehe *git help branch*.
 258
 259 Der ``master'' 'Branch' ist ein nützlicher Brauch. Andere können davon
 260 ausgehen, dass dein 'Repository' einen 'Branch' mit diesem Namen hat und
 261 dass er die offizielle Version enthält. Auch wenn du den ``master'' 'Branch'
 262 umbenennen oder auslöschen könntest, kannst du diese Konvention aber auch
 263 respektieren.
 264
 265 === Temporäre 'Branches' ===
 266
 267 Nach einer Weile wirst du feststellen, dass du regelmäßig kurzlebige
 268 'Branches' erzeugst, meist aus dem gleichen Grund: jeder neue 'Branch' dient
 269 lediglich dazu, den aktuellen Stand zu sichern, damit du kurz zu einem alten
 270 Stand zurück kannst um eine vorrangige Fehlerbehebung zu machen oder
 271 irgendetwas anderes.
 272
 273 Es ist vergleichbar mit dem kurzzeitigen Umschalten des Fernsehkanals um zu
 274 sehen was auf dem anderen Kanal los ist. Doch anstelle ein paar Knöpfe zu
 275 drücken, machst du 'create', 'check out', 'merge' und 'delete' von
 276 temporären 'Branches'. Glücklicherweise hat Git eine Abkürzung dafür, die
 277 genauso komfortabel ist wie eine Fernbedienung:
 278
 279  $ git stash
 280
 281 Das sichert den aktuellen Stand an einem temporären Ort ('stash'=Versteck)
 282 und stellt den vorherigen Stand wieder her. Dein Arbeitsverzeichnis
 283 erscheint wieder exakt in dem Zustand wie es war, bevor du anfingst zu
 284 editieren. Nun kannst du Fehler beheben, Änderungen vom zentralen
 285 'Repository' holen ('pull') und so weiter. Wenn du wieder zurück zu deinen
 286 Änderungen willst, tippe:
 287
 288  $ git stash apply  # Es kann sein, dass du Konflikte auflösen musst.
 289
 290 Du kannst mehrere 'stashes' haben und diese unterschiedlich handhaben. Siehe
 291 *git help stash*. Wie du dir vielleicht schon gedacht hast, verwendet Git
 292 'Branches' im Hintergrund um diesen Zaubertrick durchzuführen.
 293
 294 === Arbeite wie du willst ===
 295
 296 Du magst dich fragen, ob 'Branches' diesen Aufwand Wert sind. Immerhin sind
 297 'Clone' fast genauso schnell und du kannst mit *cd* anstelle von
 298 esoterischen Git Befehlen zwischen ihnen wechseln.
 299
 300 Betrachten wir Webbrowser. Warum mehrere Tabs unterstützen und mehrere
 301 Fenster? Weil beides zu erlauben eine Vielzahl an Stilen unterstützt. Einige
 302 Anwender möchten nur ein Browserfenster geöffnet haben und benutzen Tabs für
 303 unterschiedliche Webseiten. Andere bestehen auf dem anderen Extrem: mehrere
 304 Fenster, ganz ohne Tabs. Wieder andere bevorzugen irgendetwas dazwischen.
 305
 306 'Branchen' ist wie Tabs für dein Arbeitsverzeichnis und 'Clonen' ist wie das
 307 Öffnen eines neuen Browserfenster. Diese Operationen sind schnell und lokal,
 308 also warum nicht damit experimentieren um die beste Kombination für sich
 309 selbst zu finden? Git lässt dich genauso arbeiten, wie du es willst.