| blob | 49807d3eb0a904966ab109f99883323165010c5d |
1 gittutorial(7)
2 ==============
4 NAME
5 ----
6 gittutorial - Eine einführende Anleitung zu git (für Version 1.5.1 oder höher)
8 SYNOPSIS
9 --------
10 git *
12 DESCRIPTION
13 -----------
14 Diese Anleitung erklärt, wie man ein neues Projekt nach git importiert,
15 Änderungen daran vornimmt und diese mit anderen Entwicklern teilt.
17 Wenn Sie hauptsächlich daran interessiert sind, git zu verwenden, um ein
18 Projekt herunterzuladen, beispielsweise um die neuste Version zu testen,
19 könnten Sie es vorziehen, mit den ersten zwei Kapiteln des
20 link:user-manual.html[Gitbenutzerhandbuches] zu beginnen.
22 Zunächst sollten Sie wissen, dass sie die Dokumentation für ein
23 Kommando wie `git log --graph` beziehen können mit:
25 ------------------------------------------------
26 $ man git-log
27 ------------------------------------------------
29 Es ist eine gute Idee, sich selbt mit Namen und öffentlicher E-Mail
30 Adresse git vorzustellen, bevor irgendwelche Handlungen vorgenommen
31 werden. Der einfachste Weg, dies zu tun ist:
33 ------------------------------------------------
34 $ git config --global user.name "Ihr Name"
35 $ git config --global user.email ihre@e-mail_adresse.com
36 ------------------------------------------------
39 Ein neues neues Projekt importieren
40 -----------------------------------
42 Angenommen, Sie haben einen Tarball projekt.tar.gz mit Ihrer änfänglichen
43 Arbeit, können Sie es folgendermassen unter git-Revisionskontrolle stellen.
45 ------------------------------------------------
46 $ tar xzf projekt.tar.gz
47 $ cd projekt
48 $ git init
49 ------------------------------------------------
51 Git wird so antworten:
53 ------------------------------------------------
54 Initialized empty Git repository in .git/
55 ------------------------------------------------
57 Sie haben nun das momentane Verzeichnis initialisiert -- Sie sollten
58 ein neuerstelltes Verzeichnis namens ".git" bemerken können.
60 Danach weisen Sie git mit 'git-add' (beachten Sie den '.') dazu an,
61 einen Schnappschuss des Inhaltes aller Dateien im momentanen Verzeichnis
62 anzufertigen.
64 ------------------------------------------------
65 $ git add .
66 ------------------------------------------------
68 Dieser Schnappschuss wird nun in einem temporären Sammelpunkt, welcher git
69 den "Index" nennt, abgelegt. Sie können den Inhalt des Indexes permanent
70 im Repository via 'git-commit' ablegen:
72 ------------------------------------------------
73 $ git commit
74 ------------------------------------------------
76 Dies wird Sie nach einer "Commit-Nachricht", also einer Nachricht über
77 den Commit, fragen. Sie haben nun die erste Version Ihres Projektes in
78 git abgelegt.
80 Änderungen vornehmen
81 --------------------
83 Verändern Sie einige Dateien und fügen Sie den aktualisierten Inhalt
84 dem Index hinzu:
86 ------------------------------------------------
87 $ git add file1 file2 file3
88 ------------------------------------------------
90 Sie können nun wieder einen Commit ausführen. Sie können mit 'git-diff'
91 und der --cached option überprüfen, was genau bei diesemm Commit
92 ausgeführt wird:
94 ------------------------------------------------
95 $ git diff --cached
96 ------------------------------------------------
98 (Ohne --cached zeigt 'git-diff' alle Änderungen, die Sie durchgeführt,
99 aber noch nicht zum Index hinzugefügt haben.) Sie können auch eine
100 kurze Zusammenfassung der momentanen Situation mit 'git-status' erhalten:
102 ------------------------------------------------
103 $ git status
104 # On branch master
105 # Changes to be committed:
106 # (use "git reset HEAD <file>..." to unstage)
107 #
108 # modified: file1
109 # modified: file2
110 # modified: file3
111 #
112 ------------------------------------------------
114 Wenn Sie weitere Anpassungen vornehmen müssen, tun Sie dies und fügen
115 Sie dann alle neu veränderten Dateien dem Index hinzu. Schliesslich
116 führen Sie einen Commit mit Ihren Änderungen aus via:
118 ------------------------------------------------
119 $ git commit
120 ------------------------------------------------
122 This will again prompt you for a message describing the change, and then
123 record a new version of the project.
124 Dies wird Sie erneut nach einer Commit-Nachricht fragen, die die Änderung
125 erklärt und dann eine neue Version des Projektes erfassen.
127 Anstatt 'git-add' zuvor auszuführen, können Sie auch
129 ------------------------------------------------
130 $ git commit -a
131 ------------------------------------------------
133 benutzen, was automatisch alle veränderten (aber nicht alle neuen) Dateien
134 heraussucht, dem Index hinzufügt und einen Commit ausführt. Alles in einem Schritt.
136 Eine Anmerkung zu den Commit-Nachrichten: Obwohl sie nicht erforderlich
137 sind, ist es eine gute Idee, die Commit-Nachricht mit einer einzelnen,
138 kurzen (weniger als 50 Zeichen lang), zusammenfassenden Zeile zu beginnen,
139 gefolgt von einer leeren Linie und dann einer gründlicheren Erklärung.
140 Werkzeuge, beispielsweise, die Commits zu einer E-Mail umwandeln, verwenden
141 die erste Zeile als Zeile für den Subject:-Header und den Rest der
142 Commit-Nachricht als Inhalt der E-Mail.
144 Git verfolgt den Inhalt, nicht Dateien
145 --------------------------------------
147 Viele Revisionskontrollsysteme stellen ein Kommando `add` bereit, welches
148 dem System mitteilt, des solle mit der Verfolgung der Änderungen einer
149 Datei beginnen. Das Kommando `add` in git macht etwas einfacheres und
150 mächtigeres: 'git-add' wird für beides verwendet, neue und veränderte
151 Dateien und in beiden Fällen nimmt git einen Schnappschuss der Dateien
152 und stellt den Inhalt dem Index bereit, fertig, um im nächsten Commit
153 dabei zu sein.
155 Die Projektgeschichte betrachten
156 --------------------------------
158 Sie können jederzeit die Geschichte Ihres Projektes mit
160 ------------------------------------------------
161 $ git log
162 ------------------------------------------------
164 betrachten.
166 Wenn Sie ebenfalls komplette Diffs für jeden Schritt sehen
167 möchten, können Sie diesen Befehl benutzen:
169 ------------------------------------------------
170 $ git log -p
171 ------------------------------------------------
173 Oft ist eine Übersicht der Änderungen hilfreich um ein
174 Gefühl jedes Schrittes zu erhalten.
176 ------------------------------------------------
177 $ git log --stat --summary
178 ------------------------------------------------
180 Entwicklungszweige verwalten
181 ----------------------------
183 Ein einzelnes git-Repository kann mehrere Entwicklungszweige
184 (Branches) verwalten. Um einen neuen Zweig mit Namen
185 "experimentell" zu erstellen, verwenden Sie
187 ------------------------------------------------
188 $ git branch experimental
189 ------------------------------------------------
191 Wenn Sie nun
193 ------------------------------------------------
194 $ git branch
195 ------------------------------------------------
197 ausführen, erhalten Sie eine Liste aller vorhandenen Zweige:
199 ------------------------------------------------
200 experimentell
201 * master
202 ------------------------------------------------
204 Der Zweig "experimentell" ist derjenige, den Sie gerade erstellt
205 haben und der Zweig "master" ist der Standardzweig der standardmässig
206 für Sie erstellt wurde. Der Stern bezeichnet den Zweig, auf welchem
207 Sie sich gerade befinden; verwenden Sie
209 ------------------------------------------------
210 $ git checkout experimentell
211 ------------------------------------------------
213 um in den Zweig "experimentell" zu wechseln. Nun bearbeiten Sie eine
214 Datei, führen einen Commit aus und wechseln zurück zum
215 Zweig "master":
217 ------------------------------------------------
218 (Datei bearbeiten)
219 $ git commit -a
220 $ git checkout master
221 ------------------------------------------------
223 Überprüfen Sie, dass die von Ihnen vorgenommene Änderung nicht mehr
224 sichetbar ist, da sie eigentlich auf dem Zweig "experimentell"
225 ausgeführt wurde und sie sich nun im Zweig "master" befinden.
227 Sie können eine andere Änderung im Zweig "master" vornehmen:
229 ------------------------------------------------
230 (Datei bearbeiten)
231 $ git commit -a
232 ------------------------------------------------
234 Nun weichen die Zweige von einander ab, mit jeweils anderen Änderungen.
235 Um die Änderungen im Zweig "experimental" und denjenigen im Zweig
236 "master" zusammenzuführen (mergen), benutzen Sie
238 ------------------------------------------------
239 $ git merge experimentell
240 ------------------------------------------------
242 Wenn die Änderungen nicht miteinander im Konflikt stehen, sind Sie
243 fertig. Wenn Konflikte vorhanden sind werden Markierungen in den
244 problematischen Dateien gelassen, die den Konflikt erläutern;
246 ------------------------------------------------
247 $ git diff
248 ------------------------------------------------
250 zeigt jene an. Sobald Sie die Dateien angepasst haben, um die
251 Konflikte zu lösen, verwenden Sie:
253 ------------------------------------------------
254 $ git commit -a
255 ------------------------------------------------
257 Dies wird einen Commit mit den Resultaten der Zusammenführung (Merge)
258 durchführen. Ausserdem zeigt
260 ------------------------------------------------
261 $ gitk
262 ------------------------------------------------
264 eine hübsche graphische Repräsentation der daraus resultierenden Geschichte.
266 Nun könnten Sie den Zweig "experimentell" so löschen:
268 ------------------------------------------------
269 $ git branch -d experimentell
270 ------------------------------------------------
272 Dieser Befehl versichert sich zunächst, dass alle vorgenommenen
273 Änderungen im Zweig "experimentell" bereits im aktuellen Zweig sind.
275 Wenn Sie auf einem Zweig "verrueckte-idee" entwickeln und es später
276 bereuen, können Sie den Zweig jederzeit mittels
278 -------------------------------------
279 $ git branch -D crazy-idea
280 -------------------------------------
282 löschen.
284 Zweige sind billig und einfach, deshalb ist dies ein guter Weg etwas
285 auszuprobieren.
287 Git für Zusammenarbeit verwenden
288 --------------------------------
290 Angenommen, dass Alice ein neues Projekt mit einem git-Repository in
291 /home/alice/projekt begonnen hat und dass Bob, welcher ebenfalls
292 ein Homeverzeichnis auf der selben Maschine besitzt, bei diesem
293 Projekt mitwirken will.
295 Bob beginnt mit:
297 ------------------------------------------------
298 bob$ git clone /home/alice/projekt meinrepo
299 ------------------------------------------------
301 Dies erstellt ein neues Repository "meinrepo", welcher einen "Klon"
302 von Alice' Repository darstellt. Der Klon steht auf der selben
303 Grundlage wie das Originalprojekt, besitzt aber seine eigene
304 Kopie der originalen Projektgeschichte.
306 Bob nimmt einige Änderungen vor und führt Commits aus:
308 ------------------------------------------------
309 (Dateien bearbeiten)
310 bob$ git commit -a
311 (So oft wiederholen wie nötig)
312 ------------------------------------------------
314 Wenn er fertig ist, sagt er Alice, dass sie die Änderungen seines
315 Repositorys in /home/bob/meinrepo ziehen (pullen) solle.
317 ------------------------------------------------
318 alice$ cd /home/alice/projekt
319 alice$ git pull /home/bob/meinrepo master
320 ------------------------------------------------
322 Dies führt die Änderungen von Bobs "master"-Zweig und Alice'
323 aktuellem Zweig zusammen. Falls Alice eigene Änderungen in der Zwischenzeit
324 vorgenommen hat, muss sie eventuell Konflikte von Hand lösen
325 (Beachten Sie, dass das Argument "master" im oberen Kommando eigentlich
326 unnötig ist, da dies die Standardeinstellung ist).
328 Das "pull"-Kommando führt also zwei Operationen durch: Es holt die
329 Änderungen eines fernen Zweiges und führt sie mit dem momentanen
330 Zweig zusammen.
332 Beachten Sie, dass Alice im Normalfall einen Commit mit ihren lokalen
333 Änderungen durchführen wollen würde, bevor sie den "pull" einleitet.
334 Falls Bobs Arbeit mit dem, was Alice, seit sich die Geschichte gespalten
335 hat, im Konflikt steht, würde Alice ihren Arbeitsverzeichnisbaum verwenden
336 und den Index für den Auflösungsprozess (git würde die Änderungen dennoch
337 beziehen aber sie nicht zusammenführen --- Alice muss ihre lokalen Änderungen
338 entfernen und erneut einen Pull ausführen, falls dies geschieht).
340 Alice kann zunächst betrachten, was Bob genau getan hat, ohne einen Merge
341 durchzuführen, mittels des "fetch"(holen, anfordern)-Kommandos; dieses erlaubt Alice zu
342 inspizieren, das Bob getan hat, mittels eines speziellen Symbols "FETCH_HEAD".
343 Um zu entscheiden ob er etwas besitzt, für das es sich lohnen würde, zu
344 ziehen, kann sie dies wie folgt tun:
346 ------------------------------------------------
347 alice$ git fetch /home/bob/meinrepo master
348 alice$ git log -p ..FETCH_HEAD
349 ------------------------------------------------
351 Diese Operation ist sicher, selbst wenn Alice noch keinen Commit
352 mit den lokalen Änderungen durchgeführt hat.
354 Nachdem sie unter die Lupe genommen hat, was Bob tat, wenn dort nichts
355 drinliches vorliegt, kann sie sich dazu entschliessen, weiterzuarbeiten,
356 ohne die Änderungen von Bob zu beziehen. Falls die Geschichte von Bob
357 etwas besitzt, das Alice sofort benötigt, kann Alice den Weg wählen,
358 einen Commit mit ihrem Work-in-progress auszuführen, einen Pull
359 durchführen und schliesslich weiterzuarbeiten mit den Änderungen
360 der daraus resultierenden Geschichte.
362 Wenn Sie in einer kleinen, eng verbundenen Gruppe arbeiten,
363 ist es nicht unüblich mit dem selben Repository immer und immer
364 wieder zu interagieren. Durch das definieren von 'remote' (fernen)
365 Repositories im Vorraus, können Sie es einfacher machen:
367 ------------------------------------------------
368 alice$ git remote add bob /home/bob/meinrepo
369 ------------------------------------------------
371 Damit kann Alice den ersten Teil der Pull-Operation allein mit dem Kommando 'git-fetch'
372 ohne Zusammenführung mit ihrem eigenen Zweig ausführen durch:
374 -------------------------------------
375 alice$ git fetch bob
376 -------------------------------------
378 Im Gegensatz zur langen Form, wenn Alice von Bob mittels eines
379 fernen Repositorys, welche mit 'git-remote' definiert wurden,
380 die Änderungen abruft, werden diese in einem Zweig, der
381 ein fernes Repository verfolgt, abgelegt, in diesem Falle
382 `bob/master`. Also danach:
384 -------------------------------------
385 alice$ git log -p master..bob/master
386 -------------------------------------
388 Dies zeigt eine Liste aller Änderungen die Bob, seit er einen getrennten
389 Zweig von Alice' "master"-Zweig erstellt hat, durchgeführt hat.
391 Nach dem begutachten dieser Änderungen, Alice kann die beiden
392 Zweige zusammenführen.
394 -------------------------------------
395 alice$ git merge bob/master
396 -------------------------------------
398 Dieser `merge` kann auch durch 'ziehen von ihrem fernen
399 Zweig' erreicht werden, ungefähr so:
401 -------------------------------------
402 alice$ git pull . remotes/bob/master
403 -------------------------------------
405 Beachten Sie, dass git pull mit dem aktuellen Zweig zusammenführt,
406 egal was als Argument angegeben wird.
408 Später kann Bob sein Repository mit jenem von Alice abgleichen mit
410 -------------------------------------
411 bob$ git pull
412 -------------------------------------
414 Beachten Sie, dass er den Pfad zu Alice' Repository angeben muss;
415 wenn Bob das Repoistory von Alice geklont hat, legt git den Ort
416 ihres Repositorys in der Konfiguration des Repositorys ab und dieser
417 Ort wird für das Ziehen verwendet:
419 -------------------------------------
420 bob$ git config --get remote.origin.url
421 /home/alice/projekt
422 -------------------------------------
424 (Die komplette Konfiguration, welche durch 'git-clone' erstellt wurde
425 kann mittels `git config -l` eingesehen werden und die linkgit:git-config[1]
426 man page erklärt die Bedeutung jeder Option.)
428 Git behält ausserdem eine unverfälschte Kopie von Alice' "master"-Zweiges
429 unter dem Namen "origin/master":
431 -------------------------------------
432 bob$ git branch -r
433 origin/master
434 -------------------------------------
436 Falls Bob sich später dazu entscheidet, von einem anderen Host
437 zu arbeiten, kann er immer noch klonen und ziehen durch das
438 SSH-Protokoll:
440 -------------------------------------
441 bob$ git clone alice.org:/home/alice/projekt meinrepo
442 -------------------------------------
444 Alternativ besitzt git auch ein natives Protokoll, oder er kann
445 rsync oder HTTP verwenden; siehe linkgit:git-pull[1] für Genaueres.
447 Git kann auch in einem CVS-ähnlichen Modus verwendet werden, mit einem
448 zentralen Repository, in welches verschiedene Benutzer Änderungen
449 versenden (push); siehe linkgit:git-push[1] und linkgit:gitcvs-migration[7].
451 Die Geschichte erkunden
452 -----------------------
454 Die Git-Geschichte wird als eine Serie von untereinander miteinander
455 in Beziehung stehenden Commits represäntiert. Sie haben bereits gesehen,
456 dass das 'git-log' Kommando diese Commits auflisten kann.
457 Beachten Sie, dass die erste Zeile jedes Git-Logeintrages auch den
458 Namen des Commits ausgibt:
460 -------------------------------------
461 $ git log
462 commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
463 Author: Junio C Hamano <junkio@cox.net>
464 Date: Tue May 16 17:18:22 2006 -0700
466 merge-base: Die Kommentare über das Post-processing klarer gestaltet.
467 -------------------------------------
469 Sie können diesen Namen 'git-show' übergeben, um Details über den
470 Commit zu erfahren.
472 -------------------------------------
473 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
474 -------------------------------------
476 Aber es gibt noch andere Wege, um auf Commits zu referenzieren. Sie
477 können irgendeinen anfänglichen Teil des Commits nehmen, der lange genug
478 ist, um den Commit zu identifizieren:
480 -------------------------------------
481 $ git show c82a22c39c # die ersten paar Zeichen des Namens
482 # reichen normalerweise
483 $ git show HEAD # die Spitze des aktuellen Zweiges
484 $ git show experimentell # die Spitze des "experimentell"-Zweiges
485 -------------------------------------
487 Jeder Commit hat normalerweise einen "Eltern" (parent)-Commit,
488 welcher auf den vorherigen Status des Projekts zeigt:
490 -------------------------------------
491 $ git show HEAD^ # um den Eltern-Commit von HEAD zu sehen
492 $ git show HEAD^^ # um den Grosseltern-Commit von HEAD zu sehen
493 $ git show HEAD~4 # um den Urgrosseltern-Commit von HEAD zu sehen
494 -------------------------------------
496 Beachten Sie, dass zusammengeführte Commits mehr als einen
497 Eltern-Commit besitzen können:
499 -------------------------------------
500 $ git show HEAD^1 # Den ersten Eltern-Commit von HEAD (das Selbe wie HEAD^) einsehen
501 $ git show HEAD^2 # Den zweiten Eltern-Commit von HEAD einsehen
502 -------------------------------------
504 Sie können auch selbst Commits namen geben; nach
506 -------------------------------------
507 $ git tag v2.5 1b2e1d63ff
508 -------------------------------------
510 Können Sie auf 1b2e1d63ff mit dem Namen "v2.5" referenzieren. Falls
511 Sie diesen Namen mit anderen teilen möchten (zum Beispiel, um eine
512 Releaseversion zu identifizieren), sollten Sie ein "tag"-Objekt erstellen
513 und es eventuell noch signieren; siehe linkgit:git-tag[1] für Details.
515 Jeder Git-Befehl der einen Commit wissen möchte, kann jeden dieser
516 Namen verwenden. Beispiel:
518 -------------------------------------
519 $ git diff v2.5 HEAD # den akutellen HEAD mit v2.5 vergleichen
520 $ git branch stable v2.5 # Einen neuen Zweig mit Namen "stable" auf
521 # Basis von v2.5 erzeugen
522 $ git reset --hard HEAD^ # Den aktuellen Zweig und das aktuelle Arbeitsverzeichnis
523 # zurücksetzen auf seinen Status in HEAD^
524 -------------------------------------
526 Seien Sie vorsichtig mit dem vorherigen Kommando: Zusätzlich zum verlieren
527 aller Änderungen im aktuellen Arbeitsverzeichnis, werden auch noch
528 alle späteren Commits dieses Zweigs gelöscht. Wenn dieser Zweig
529 der einzige ist welcher diese Commits enthält, gehen diese verloren.
530 Ausserdem, benutzen Sie 'git-reset' nicht auf einem öffentlich
531 einsehbaren Zweig von der andere Entwickler ziehen, da es sinnlose
532 Zusammenführungen erzwingt und die Geschichte gesäubert werden muss.
533 Falls Sie irgendwelche Änderungen rückgängig machen müssen, die
534 Sie versendet haben, sollten Sie stattdessen 'git-revert' benutzen.
536 Der Befehl 'git-grep' kann nach Strings in einer beliebigen Version
537 Ihres Projektest suchen, also sucht
539 -------------------------------------
540 $ git grep "hallo" v2.5
541 -------------------------------------
543 nach allen Vorkommnissen von "hallo" in v2.5.
545 Falls Sie den Namen des Commits nicht angeben sucht 'git-grep' in
546 den Dateien in ihrem aktuellen Arbeitsverzeichnis.
548 -------------------------------------
549 $ git grep "hello"
550 -------------------------------------
552 ist also ein einfacher Weg, nur die Dateien zu durchsuchen, die
553 git verwaltet.
555 Viele git-Befehle können auch mehrere Commits als Argumente annehmen,
556 welche verschieden ausgedrückt werden können. Hier einige Beispiele
557 mit 'git-log':
559 -------------------------------------
560 $ git log v2.5..v2.6 # Commits zwischen v2.5 und v2.6
561 $ git log v2.5.. # Commits seit v2.5
562 $ git log --since="2 weeks ago" # Commits der letzten 2 Wochen
563 $ git log v2.5.. Makefile # Commits seit v2.5 in welchen
564 # Makefile bearbeitet wurde
565 -------------------------------------
567 Sie können 'git-log' auch einen "Bereich" (range) von Commits angeben,
568 wovon der Erste nicht unbeding ein Vorfahre des Zweiten sein muss;
569 zum Beispiel, wenn die Spitzen der Zweige "stabil" und "experimentell"
570 sich getrennt haben von einem gemeinsamen Commit, dann zeigt
572 -------------------------------------
573 $ git log stabil..experimentell
574 -------------------------------------
576 die Commits an, die im Zweig "experimentell" aber nicht im Zweig
577 "stabil" getätigt wurden. Dagegen zeigt
579 -------------------------------------
580 $ git log experimentell..stabil
581 -------------------------------------
583 die Commits an, die im Zweig "stabil" aber nicht im Zweig
584 "experimentell" vorgenommen wurden.
586 Das 'git-log'-Kommando hat eine Schwäche: Es muss Commits in einer
587 Liste anzeigen. Wenn die Geschichte Entwicklungszweige enthält,
588 die sich getrennt und wieder zusammengeführt haben, ist die Reihenfolge,
589 in welcher 'git-log' die Commits anzeigt, bedeutungslos.
591 Die meisten Projekte mit mehreren Mitwirkenden (wie der Linuxkernel
592 oder git selbst) haben häufige Zusammenführungen. 'gitk' funktioniert
593 in diesem Falle besser, um die Projektgeschichte zu visualisieren.
594 Beispielsweise
596 -------------------------------------
597 $ gitk --since="2 weeks ago" treiber/
598 -------------------------------------
600 erlaubt Ihnen, die Commits der letzten zwei Wochen im "treiber"-Verzeichnis
601 durchzusehen (Hinweis: Sie können die Schriften von gitk anpassen,
602 indem Sie die Strg- oder die Control-Taste gedrückt halten und "+" oder
603 "-" drücken).
605 Die meisten Befehle, die Dateinamen als Argumente akzeptieren, erlauben
606 Ihnen optional auch einen Commit dem Dateinamen voranzustellen, um
607 eine bestimmte Version der Datei anzugeben:
609 -------------------------------------
610 $ git diff v2.5:Makefile HEAD:Makefile.in
611 -------------------------------------
613 Sie können auch 'git-show' verwenden, um eine solche Datei einzusehen:
615 -------------------------------------
616 $ git show v2.5:Makefile
617 -------------------------------------
619 Nächste Schritte
620 ----------------
622 Diese Anleitung sollte für grundlegende verteilte Revisionskontrolle
623 Ihrer Projekte reichen. Um jedoch die Tiefe und Macht von git komplett
624 zu verstehen, müssen Sie zwei einfache Ideen verstehen, auf welchen
625 git basiert:
627 * Die Objektdatenbank ist die eher elegante Methode, um die
628 Geschichte ihrer Projektdateien, -verzeichnisse und -commits
629 abzulegen
631 * Die Indexdatei ist ein Zwischenspeicher des Status eines
632 Verzeichnisbaumes, der verwendet wird, um Bereitstellungen
633 zu erzeugen, Arbeitsverzeichnisse umzustellen und die verschiedenen
634 in einer Zusammenführung involvierten Bäume zu behalten.
636 Teil zwei dieser Anleitung erklärt die Objektdatenbank, die Bereitstellung
637 und einige andere Kleinigkeiten die Sie benötigen um das meiste aus git
638 herauszuholen. Es befindet sich unter linkgit:gittutorial-2[7].
640 Falls Sie nicht gleich damit weiterfahren wollen, einige dieser
641 Exkurse können nun interessant sein:
643 * linkgit:git-format-patch[1], linkgit:git-am[1]: Diese wandeln
644 eine Serie von Giteintragungen in als E-Mail versandte Patches um
645 und umgekehrt. Nützlich für Projekte wie den Linuxkernel, welcher
646 stark auf per E-Mail versandten Patches basiert.
648 * linkgit:git-bisect[1]: Falls sich ein Rückschritt im Projekt befindet,
649 ein Weg, das Problem zu finden, ist das Suchen in der Geschichte um
650 die exakte Eintragung zu finden, welche daran schuld ist. Git bisect
651 kann Ihnen helfen, eine Binärsuche nach diesem Commit zu starten.
652 Es ist clever genug, um eine fast-optimale Suche auszuführen, selbst im
653 Falle einer komplexen, nicht-linearen Geschichte mit vielen
654 zusammengeführten Zweigen.
656 * link:everyday.html[Tägliches GIT mit 20 Befehlen oder so]
658 * linkgit:gitcvs-migration[7]: Git für CVS-Benutzer.
660 SEE ALSO
661 --------
662 linkgit:gittutorial-2[7],
663 linkgit:gitcvs-migration[7],
664 linkgit:gitcore-tutorial[7],
665 linkgit:gitglossary[7],
666 link:everyday.html[Tägliches git],
667 link:user-manual.html[The Git User's Manual]
669 GIT
670 ---
671 Teil der linkgit:git[1] Suite.