de/basic.txt

   1 == Erste Schritte ==
   2
   3 Bevor wir uns in ein Meer von Git-Befehlen stürzen, schauen wir uns ein paar
   4 einfache Beispiele an. Trotz ihrer Einfachheit sind alle davon wichtig und
   5 nützlich. Um ehrlich zu sein, in meinen ersten Monaten mit Git brauchte ich nicht
   6 mehr, als in diesem Kapitel beschrieben steht.
   7
   8 === Stand sichern ===
   9
  10 Hast Du gravierende Änderungen vor? Nur zu, aber speichere Deinen aktuellen
  11 Stand vorher lieber nochmal ab:
  12
  13  $ git init
  14  $ git add .
  15  $ git commit -m "Meine erste Sicherung"
  16
  17 Falls deine Änderungen schief gehen, kannst du jetzt die alte Version
  18 wiederherstellen:
  19
  20  $ git reset --hard
  21
  22 Um den neuen Stand zu sichern:
  23
  24  $ git commit -a -m "Eine andere Sicherung"
  25
  26 === Hinzufügen, Löschen, Umbenennen ===
  27
  28 Bisher kümmert sich Git nur um Dateien, die existierten, als Du das erste
  29 Mal *git add* ausgeführt hast. Wenn Du Dateien oder Verzeichnisse
  30 hinzufügst, musst du Git das mitteilen:
  31
  32  $ git add readme.txt Dokumentation
  33
  34 Ebenso, wenn Git Dateien vergessen soll:
  35
  36  $ git rm ramsch.h veraltet.c
  37  $ git rm -r belastendes/material/
  38
  39 Git löscht diese Dateien für Dich, falls Du es noch nicht getan hast.
  40
  41 Eine Datei umzubenennen, ist das selbe, wie sie zu löschen und unter neuem
  42 Namen hinzuzufügen. Git benutzt hierzu die Abkürzung *git mv*, welche die
  43 gleiche Syntax wie *mv* hat. Zum Beispiel:
  44
  45  $ git mv fehler.c feature.c
  46
  47 === Fortgeschrittenes Rückgängig machen/Wiederherstellen ===
  48
  49 Manchmal möchtest Du einfach zurückgehen und alle Änderungen ab einem
  50 bestimmten Zeitpunkt verwerfen, weil sie falsch waren. Dann:
  51
  52  $ git log
  53
  54 zeigt Dir eine Liste der bisherigen 'Commits' und deren SHA1 Hashwerte:
  55
  56 ----------------------------------
  57 commit 766f9881690d240ba334153047649b8b8f11c664
  58 Author: Bob <bob@example.com>
  59 Date:   Tue Mar 14 01:59:26 2000 -0800
  60
  61     Ersetze printf() mit write().
  62
  63 commit 82f5ea346a2e651544956a8653c0f58dc151275c
  64 Author: Alice <alice@example.com>
  65 Date:   Thu Jan 1 00:00:00 1970 +0000
  66
  67     Initial commit.
  68 ----------------------------------
  69
  70 Die ersten paar Zeichen eines Hashwert reichen aus, um einen 'Commit' zu
  71 identifizieren; alternativ benutze kopieren und einfügen für den kompletten
  72 Hashwert. Gib ein:
  73
  74  $ git reset --hard 766f
  75
  76 um den Stand eines bestimmten 'Commits' wieder herzustellen und alle
  77 nachfolgenden Änderungen für immer zu löschen.
  78
  79 Ein anderes Mal willst Du nur kurz zu einem älteren Stand springen. In
  80 diesem Fall, gib folgendes ein:
  81
  82  $ git checkout 82f5
  83
  84 Damit springst Du in der Zeit zurück, behältst aber neuere Änderungen. Aber,
  85 wie bei Zeitreisen in einem Science-Fiction-Film, wenn Du jetzt etwas
  86 änderst und 'commitest', gelangst Du in eine alternative Realität, denn Deine
  87 Änderungen sind anders als beim früheren 'Commit'.
  88
  89 Diese alternative Realität heißt 'Branch', und <<branch,wir kommen später
  90 darauf zurück>>. Für jetzt merke Dir,
  91
  92  $ git checkout master
  93
  94 bringt Dich wieder in die Gegenwart. Um zu verhindern, dass sich Git
  95 beschwert, solltest Du vor einem 'Checkout' alle Änderungen 'commiten' oder
  96 'reseten'.
  97
  98 Um wieder die Computerspielanalogie anzuwenden:
  99
 100 - *`git reset --hard`*: Lade einen alten Stand und lösche alle Spielstände,
 101 die neuer sind als der jetzt geladene.
 102
 103 - *`git checkout`*: Lade einen alten Spielstand, aber wenn Du weiterspielst,
 104 wird der Spielstand von den früher gesicherten Spielständen abweichen. Jeder
 105 Spielstand, der ab jetzt gesichert wird, entsteht in dem separaten 'Branch',
 106 welcher der alternative Realität entspricht. <<branch, dazu kommen wir
 107 später>>.
 108
 109 Du kannst auch nur einzelne Dateien oder Verzeichnisse wiederherstellen,
 110 indem Du sie an den Befehl anhängst:
 111
 112  $ git checkout 82f5 eine.datei andere.datei
 113
 114 Sei vorsichtig, diese Art des '*Checkout*' kann Dateien überschreiben, ohne
 115 dass Du etwas merkst. Um Unfälle zu vermeiden, solltest Du immer 'commiten'
 116 bevor Du ein 'Checkout' machst, besonders am Anfang, wenn Du Git noch
 117 erlernst. Allgemein gilt: Wenn Du unsicher bist, egal, ob ein Git Befehl oder
 118 irgendeine andere Operation, führe zuerst *git commit -a* aus.
 119
 120 Du magst Kopieren und Einfügen von Hashes nicht? Dann nutze:
 121
 122  $ git checkout :/"Meine erste Si"
 123
 124 um zu einem 'Commit' zu springen, dessen Beschreibung so anfängt. Du kannst
 125 auch nach dem 5. letzten 'Commit' fragen:
 126
 127  $ git checkout master~5
 128
 129 === Rückgängig machen ===
 130
 131 In einem Gerichtssaal können Ereignisse aus den Akten gelöscht
 132 werden. Ähnlich kannst Du gezielt 'Commits' rückgängig machen.
 133
 134  $ git commit -a
 135  $ git revert 1b6d
 136
 137 wird den 'Commit' mit dem angegebenen Hashwert rückgängig machen. Das
 138 Rückgängig machen wird als neuer 'Commit' erstellt, was mit *git log*
 139 überprüft werden kann.
 140
 141 === Changelog erstellen ===
 142
 143 Verschiedene Projekte benötigen ein
 144 http://de.wikipedia.org/wiki/%C3%84nderungsprotokoll[Änderungsprotokoll].
 145 Das kannst du mit folgendem Befehl erstellen:
 146
 147  $ git log > ChangeLog
 148
 149 === Dateien herunterladen ===
 150
 151 Eine Kopie eines mit Git verwalteten Projekts bekommst du mit:
 152
 153  $ git clone git://server/pfad/zu/dateien
 154
 155 Um zum Beispiel alle Dateien zu bekommen, die ich zum Erzeugen dieser Seiten
 156 benutze:
 157
 158  $ git clone git://git.or.cz/gitmagic.git
 159
 160 Es gibt gleich noch viel mehr über den 'clone' Befehl zu sagen.
 161
 162 === Das Neueste vom Neuen ===
 163
 164 Wenn Du schon eine Kopie eines Projektes hast, kannst Du es auf die neuste
 165 Version aktualisieren mit:
 166
 167  $ git pull
 168
 169 === Einfaches Veröffentlichen ===
 170
 171 Angenommen Du hast ein Skript geschrieben und möchtest es anderen zugänglich
 172 machen. Du könntest sie einfach bitten, es von Deinem Computer
 173 herunterzuladen, aber falls sie das tun, während Du experimentierst oder das
 174 Skript verbesserst, könnten sie in Schwierigkeiten geraten. Genau deswegen
 175 gibt es Releasezyklen. Entwickler arbeiten regelmäßig an einem Projekt,
 176 veröffentlichen den Code aber nur, wenn sie ihn für vorzeigbar halten.
 177
 178 Um dies in Git zu tun, gehe ins Verzeichnis in dem das Skript liegt:
 179
 180  $ git init
 181  $ git add .
 182  $ git commit -m "Erster Stand"
 183
 184 Dann sage Deinen Nutzern:
 185
 186  $ git clone dein.computer:/pfad/zum/skript
 187
 188 um Dein Skript herunterzuladen. Das setzt voraus, dass sie einen SSH-Zugang
 189 haben. Falls nicht, führe *git deamon* aus und sage den Nutzern folgendes:
 190
 191  $ git clone git://dein.computer/pfad/zum/skript
 192
 193 Ab jetzt, immer wenn Dein Skript reif für eine Veröffentlichung ist:
 194
 195  $ git commit -a -m "Nächster Stand"
 196
 197 und Deine Nutzer können ihr Skript aktualisieren mit:
 198
 199  $ git pull
 200
 201 Deine Nutzer werden nie mit Versionen in Kontakt kommen, von denen Du es
 202 nicht willst. Natürlich funktioniert der Trick für fast alles, nicht nur
 203 Skripts.
 204
 205 === Was habe ich getan? ===
 206
 207 Finde heraus, was Du seit dem letzten 'Commit' getan hast:
 208
 209  $ git diff
 210
 211 Oder seit Gestern:
 212
 213  $ git diff "@{gestern}"
 214
 215 Oder zwischen irgendeiner Version und der vorvorletzten:
 216
 217  $ git diff 1b6d "master~2"
 218
 219 Jedes mal ist die Ausgabe ein 'Patch', der mit *git apply* eingespielt werden
 220 kann. Versuche auch:
 221
 222  $ git whatchanged --since="2 weeks ago"
 223
 224 Um mir die Geschichte eines 'Repositories' anzuzeigen, benutze ich häufig
 225 http://sourceforge.net/projects/qgit[qgit] da es eine schicke
 226 Benutzeroberfläche hat, oder http://jonas.nitro.dk/tig/[tig], eine
 227 Konsolenanwendung, die sehr gut über langsame Verbindungen
 228 funktioniert. Alternativ kannst Du einen Webserver installieren mit *git
 229 instaweb*, dann kannst Du mit jedem Webbrowser darauf zugreifen.
 230
 231 === Übung ===
 232
 233 A, B, C, D sind 4 aufeinander folgende 'Commits'. B ist identisch mit A,
 234 außer, dass einige Dateien gelöscht wurden. Wir möchten die Dateien in D
 235 wieder hinzufügen, aber nicht in B. Wie machen wir das?
 236
 237 Es gibt mindestens 3 Lösungen. Angenommen, wir sind bei D:
 238
 239   1. Der Unterschied zwischen A und B sind die gelöschten Dateien. Wir
 240      können einen 'Patch' erstellen, der diesen Unterschied darstellt und
 241      diesen dann auf D anwenden:
 242
 243    $ git diff B A | git apply
 244
 245   2. Da die Dateien im 'Repository' unter dem 'Commit' A gespeichert sind,
 246      können wir sie wieder herstellen:
 247
 248    $ git checkout A foo.c bar.h
 249
 250   3. Wir können den 'Commit' von A auf B als Änderung betrachten, die wir
 251      rückgängig machen wollen:
 252
 253    $ git revert B
 254
 255 Welche Lösung ist die beste? Die, welche Dir am besten gefällt. Es ist
 256 einfach, mit Git das zu bekommen, was Du willst und oft führen viele Wege zum
 257 Ziel.