git-commit partly translated

[gitman-de.git] / gittutorial-de.txt

gittutorial(7)
==============

NAME
----
gittutorial - Eine einführende Anleitung zu git (für Version 1.5.1 oder höher)

SYNOPSIS
--------
git *

DESCRIPTION
-----------
Diese Anleitung erklärt, wie man ein neues Projekt nach git importiert,
Änderungen daran vornimmt und diese mit anderen Entwicklern teilt.

Wenn Sie hauptsächlich daran interessiert sind, git zu verwenden, um ein
Projekt herunterzuladen, beispielsweise um die neuste Version zu testen,
könnten Sie es vorziehen, mit den ersten zwei Kapiteln des
link:user-manual.html[Gitbenutzerhandbuches] zu beginnen.

Zunächst sollten Sie wissen, dass sie die Dokumentation für ein
Kommando wie `git log --graph` beziehen können mit:

------------------------------------------------
$ man git-log
------------------------------------------------

Es ist eine gute Idee, sich selbt mit Namen und öffentlicher E-Mail
Adresse git vorzustellen, bevor irgendwelche Handlungen vorgenommen
werden. Der einfachste Weg, dies zu tun ist:

------------------------------------------------
$ git config --global user.name "Ihr Name"
$ git config --global user.email ihre@e-mail_adresse.com
------------------------------------------------


Ein neues neues Projekt importieren
-----------------------------------

Angenommen, Sie haben einen Tarball projekt.tar.gz mit Ihrer änfänglichen
Arbeit, können Sie es folgendermassen unter git-Revisionskontrolle stellen.

------------------------------------------------
$ tar xzf projekt.tar.gz
$ cd projekt
$ git init
------------------------------------------------

Git wird so antworten:

------------------------------------------------
Initialized empty Git repository in .git/
------------------------------------------------

Sie haben nun das momentane Verzeichnis initialisiert -- Sie sollten
ein neuerstelltes Verzeichnis namens ".git" bemerken können.

Danach weisen Sie git mit 'git-add' (beachten Sie den '.') dazu an,
einen Schnappschuss des Inhaltes aller Dateien im momentanen Verzeichnis
anzufertigen.

------------------------------------------------
$ git add .
------------------------------------------------

Dieser Schnappschuss wird nun in einem temporären Sammelpunkt, welcher git
den "Index" nennt, abgelegt. Sie können den Inhalt des Indexes permanent
im Repository via 'git-commit' ablegen:

------------------------------------------------
$ git commit
------------------------------------------------

Dies wird Sie nach einer "Commit-Nachricht", also einer Nachricht über
den Commit, fragen. Sie haben nun die erste Version Ihres Projektes in
git abgelegt.

Änderungen vornehmen
--------------------

Verändern Sie einige Dateien und fügen Sie den aktualisierten Inhalt
dem Index hinzu:

------------------------------------------------
$ git add file1 file2 file3
------------------------------------------------

Sie können nun wieder einen Commit ausführen. Sie können mit 'git-diff'
und der --cached option überprüfen, was genau bei diesemm Commit
ausgeführt wird:

------------------------------------------------
$ git diff --cached
------------------------------------------------

(Ohne --cached zeigt 'git-diff' alle Änderungen, die Sie durchgeführt,
aber noch nicht zum Index hinzugefügt haben.) Sie können auch eine
kurze Zusammenfassung der momentanen Situation mit 'git-status' erhalten:

------------------------------------------------
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   file1
#       modified:   file2
#       modified:   file3
#
------------------------------------------------

Wenn Sie weitere Anpassungen vornehmen müssen, tun Sie dies und fügen
Sie dann alle neu veränderten Dateien dem Index hinzu. Schliesslich
führen Sie einen Commit mit Ihren Änderungen aus via:

------------------------------------------------
$ git commit
------------------------------------------------

This will again prompt you for a message describing the change, and then
record a new version of the project.
Dies wird Sie erneut nach einer Commit-Nachricht fragen, die die Änderung
erklärt und dann eine neue Version des Projektes erfassen.

Anstatt 'git-add' zuvor auszuführen, können Sie auch

------------------------------------------------
$ git commit -a
------------------------------------------------

benutzen, was automatisch alle veränderten (aber nicht alle neuen) Dateien
heraussucht, dem Index hinzufügt und einen Commit ausführt. Alles in einem Schritt.

Eine Anmerkung zu den Commit-Nachrichten: Obwohl sie nicht erforderlich
sind, ist es eine gute Idee, die Commit-Nachricht mit einer einzelnen,
kurzen (weniger als 50 Zeichen lang), zusammenfassenden Zeile zu beginnen,
gefolgt von einer leeren Linie und dann einer gründlicheren Erklärung.
Werkzeuge, beispielsweise, die Commits zu einer E-Mail umwandeln, verwenden
die erste Zeile als Zeile für den Subject:-Header und den Rest der
Commit-Nachricht als Inhalt der E-Mail.

Git verfolgt den Inhalt, nicht Dateien
--------------------------------------

Viele Revisionskontrollsysteme stellen ein Kommando `add` bereit, welches
dem System mitteilt, des solle mit der Verfolgung der Änderungen einer
Datei beginnen. Das Kommando `add` in git macht etwas einfacheres und
mächtigeres: 'git-add' wird für beides verwendet, neue und veränderte
Dateien und in beiden Fällen nimmt git einen Schnappschuss der Dateien
und stellt den Inhalt dem Index bereit, fertig, um im nächsten Commit
dabei zu sein.

Die Projektgeschichte betrachten
--------------------------------

Sie können jederzeit die Geschichte Ihres Projektes mit

------------------------------------------------
$ git log
------------------------------------------------

betrachten.

Wenn Sie ebenfalls komplette Diffs für jeden Schritt sehen
möchten, können Sie diesen Befehl benutzen:

------------------------------------------------
$ git log -p
------------------------------------------------

Oft ist eine Übersicht der Änderungen hilfreich um ein
Gefühl jedes Schrittes zu erhalten.

------------------------------------------------
$ git log --stat --summary
------------------------------------------------

Entwicklungszweige verwalten
----------------------------

Ein einzelnes git-Repository kann mehrere Entwicklungszweige
(Branches) verwalten. Um einen neuen Zweig mit Namen
"experimentell" zu erstellen, verwenden Sie

------------------------------------------------
$ git branch experimental
------------------------------------------------

Wenn Sie nun

------------------------------------------------
$ git branch
------------------------------------------------

ausführen, erhalten Sie eine Liste aller vorhandenen Zweige:

------------------------------------------------
  experimentell
* master
------------------------------------------------

Der Zweig "experimentell" ist derjenige, den Sie gerade erstellt
haben und der Zweig "master" ist der Standardzweig der standardmässig
für Sie erstellt wurde. Der Stern bezeichnet den Zweig, auf welchem
Sie sich gerade befinden; verwenden Sie

------------------------------------------------
$ git checkout experimentell
------------------------------------------------

um in den Zweig "experimentell" zu wechseln. Nun bearbeiten Sie eine
Datei, führen einen Commit aus und wechseln zurück zum
Zweig "master":

------------------------------------------------
(Datei bearbeiten)
$ git commit -a
$ git checkout master
------------------------------------------------

Überprüfen Sie, dass die von Ihnen vorgenommene Änderung nicht mehr
sichetbar ist, da sie eigentlich auf dem Zweig "experimentell"
ausgeführt wurde und sie sich nun im Zweig "master" befinden.

Sie können eine andere Änderung im Zweig "master" vornehmen:

------------------------------------------------
(Datei bearbeiten)
$ git commit -a
------------------------------------------------

Nun weichen die Zweige von einander ab, mit jeweils anderen Änderungen.
Um die Änderungen im Zweig "experimental" und denjenigen im Zweig
"master" zusammenzuführen (mergen), benutzen Sie

------------------------------------------------
$ git merge experimentell
------------------------------------------------

Wenn die Änderungen nicht miteinander im Konflikt stehen, sind Sie
fertig. Wenn Konflikte vorhanden sind werden Markierungen in den
problematischen Dateien gelassen, die den Konflikt erläutern;

------------------------------------------------
$ git diff
------------------------------------------------

zeigt jene an. Sobald Sie die Dateien angepasst haben, um die
Konflikte zu lösen, verwenden Sie:

------------------------------------------------
$ git commit -a
------------------------------------------------

Dies wird einen Commit mit den Resultaten der Zusammenführung (Merge)
durchführen. Ausserdem zeigt

------------------------------------------------
$ gitk
------------------------------------------------

eine hübsche graphische Repräsentation der daraus resultierenden Geschichte.

Nun könnten Sie den Zweig "experimentell" so löschen:

------------------------------------------------
$ git branch -d experimentell
------------------------------------------------

Dieser Befehl versichert sich zunächst, dass alle vorgenommenen
Änderungen im Zweig "experimentell" bereits im aktuellen Zweig sind.

Wenn Sie auf einem Zweig "verrueckte-idee" entwickeln und es später
bereuen, können Sie den Zweig jederzeit mittels

-------------------------------------
$ git branch -D crazy-idea
-------------------------------------

löschen.

Zweige sind billig und einfach, deshalb ist dies ein guter Weg etwas
auszuprobieren.

Git für Zusammenarbeit verwenden
--------------------------------

Angenommen, dass Alice ein neues Projekt mit einem git-Repository in
/home/alice/projekt begonnen hat und dass Bob, welcher ebenfalls
ein Homeverzeichnis auf der selben Maschine besitzt, bei diesem
Projekt mitwirken will.

Bob beginnt mit:

------------------------------------------------
bob$ git clone /home/alice/projekt meinrepo
------------------------------------------------

Dies erstellt ein neues Repository "meinrepo", welcher einen "Klon"
von Alice' Repository darstellt. Der Klon steht auf der selben
Grundlage wie das Originalprojekt, besitzt aber seine eigene
Kopie der originalen Projektgeschichte.

Bob nimmt einige Änderungen vor und führt Commits aus:

------------------------------------------------
(Dateien bearbeiten)
bob$ git commit -a
(So oft wiederholen wie nötig)
------------------------------------------------

Wenn er fertig ist, sagt er Alice, dass sie die Änderungen seines
Repositorys in /home/bob/meinrepo ziehen (pullen) solle.

------------------------------------------------
alice$ cd /home/alice/projekt
alice$ git pull /home/bob/meinrepo master
------------------------------------------------

Dies führt die Änderungen von Bobs "master"-Zweig und Alice'
aktuellem Zweig zusammen. Falls Alice eigene Änderungen in der Zwischenzeit
vorgenommen hat, muss sie eventuell Konflikte von Hand lösen
(Beachten Sie, dass das Argument "master" im oberen Kommando eigentlich
unnötig ist, da dies die Standardeinstellung ist).

Das "pull"-Kommando führt also zwei Operationen durch: Es holt die
Änderungen eines fernen Zweiges und führt sie mit dem momentanen
Zweig zusammen.

Beachten Sie, dass Alice im Normalfall einen Commit mit ihren lokalen
Änderungen durchführen wollen würde, bevor sie den "pull" einleitet.
Falls Bobs Arbeit mit dem, was Alice, seit sich die Geschichte gespalten
hat, im Konflikt steht, würde Alice ihren Arbeitsverzeichnisbaum verwenden
und den Index für den Auflösungsprozess (git würde die Änderungen dennoch
beziehen aber sie nicht zusammenführen --- Alice muss ihre lokalen Änderungen
entfernen und erneut einen Pull ausführen, falls dies geschieht).

Alice kann zunächst betrachten, was Bob genau getan hat, ohne einen Merge
durchzuführen, mittels des "fetch"(holen, anfordern)-Kommandos; dieses erlaubt Alice zu
inspizieren, das Bob getan hat, mittels eines speziellen Symbols "FETCH_HEAD".
Um zu entscheiden ob er etwas besitzt, für das es sich lohnen würde, zu
ziehen, kann sie dies wie folgt tun:

------------------------------------------------
alice$ git fetch /home/bob/meinrepo master
alice$ git log -p ..FETCH_HEAD
------------------------------------------------

Diese Operation ist sicher, selbst wenn Alice noch keinen Commit
mit den lokalen Änderungen durchgeführt hat.

Nachdem sie unter die Lupe genommen hat, was Bob tat, wenn dort nichts
drinliches vorliegt, kann sie sich dazu entschliessen, weiterzuarbeiten,
ohne die Änderungen von Bob zu beziehen. Falls die Geschichte von Bob
etwas besitzt, das Alice sofort benötigt, kann Alice den Weg wählen,
einen Commit mit ihrem Work-in-progress auszuführen, einen Pull
durchführen und schliesslich weiterzuarbeiten mit den Änderungen
der daraus resultierenden Geschichte.

Wenn Sie in einer kleinen, eng verbundenen Gruppe arbeiten,
ist es nicht unüblich mit dem selben Repository immer und immer
wieder zu interagieren. Durch das definieren von 'remote' (fernen)
Repositories im Vorraus, können Sie es einfacher machen:

------------------------------------------------
alice$ git remote add bob /home/bob/meinrepo
------------------------------------------------

Damit kann Alice den ersten Teil der Pull-Operation allein mit dem Kommando 'git-fetch'
ohne Zusammenführung mit ihrem eigenen Zweig ausführen durch:

-------------------------------------
alice$ git fetch bob
-------------------------------------

Im Gegensatz zur langen Form, wenn Alice von Bob mittels eines
fernen Repositorys, welche mit 'git-remote' definiert wurden,
die Änderungen abruft, werden diese in einem Zweig, der
ein fernes Repository verfolgt, abgelegt, in diesem Falle
`bob/master`. Also danach:

-------------------------------------
alice$ git log -p master..bob/master
-------------------------------------

Dies zeigt eine Liste aller Änderungen die Bob, seit er einen getrennten
Zweig von Alice' "master"-Zweig erstellt hat, durchgeführt hat.

Nach dem begutachten dieser Änderungen, Alice kann die beiden
Zweige zusammenführen.

-------------------------------------
alice$ git merge bob/master
-------------------------------------

Dieser `merge` kann auch durch 'ziehen von ihrem fernen
Zweig' erreicht werden, ungefähr so:

-------------------------------------
alice$ git pull . remotes/bob/master
-------------------------------------

Beachten Sie, dass git pull mit dem aktuellen Zweig zusammenführt,
egal was als Argument angegeben wird.

Später kann Bob sein Repository mit jenem von Alice abgleichen mit

-------------------------------------
bob$ git pull
-------------------------------------

Beachten Sie, dass er den Pfad zu Alice' Repository angeben muss;
wenn Bob das Repoistory von Alice geklont hat, legt git den Ort
ihres Repositorys in der Konfiguration des Repositorys ab und dieser
Ort wird für das Ziehen verwendet:

-------------------------------------
bob$ git config --get remote.origin.url
/home/alice/projekt
-------------------------------------

(Die komplette Konfiguration, welche durch 'git-clone' erstellt wurde
kann mittels `git config -l` eingesehen werden und die linkgit:git-config[1]
man page erklärt die Bedeutung jeder Option.)

Git behält ausserdem eine unverfälschte Kopie von Alice' "master"-Zweiges
unter dem Namen "origin/master":

-------------------------------------
bob$ git branch -r
  origin/master
-------------------------------------

Falls Bob sich später dazu entscheidet, von einem anderen Host
zu arbeiten, kann er immer noch klonen und ziehen durch das
SSH-Protokoll:

-------------------------------------
bob$ git clone alice.org:/home/alice/projekt meinrepo
-------------------------------------

Alternativ besitzt git auch ein natives Protokoll, oder er kann
rsync oder HTTP verwenden; siehe linkgit:git-pull[1] für Genaueres.

Git kann auch in einem CVS-ähnlichen Modus verwendet werden, mit einem
zentralen Repository, in welches verschiedene Benutzer Änderungen
versenden (push); siehe linkgit:git-push[1] und linkgit:gitcvs-migration[7].

Die Geschichte erkunden
-----------------------

Die Git-Geschichte wird als eine Serie von untereinander miteinander
in Beziehung stehenden Commits represäntiert. Sie haben bereits gesehen,
dass das 'git-log' Kommando diese Commits auflisten kann.
Beachten Sie, dass die erste Zeile jedes Git-Logeintrages auch den
Namen des Commits ausgibt:

-------------------------------------
$ git log
commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Author: Junio C Hamano <junkio@cox.net>
Date:   Tue May 16 17:18:22 2006 -0700

    merge-base: Die Kommentare über das Post-processing klarer gestaltet.
-------------------------------------

Sie können diesen Namen 'git-show' übergeben, um Details über den
Commit zu erfahren.

-------------------------------------
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------

Aber es gibt noch andere Wege, um auf Commits zu referenzieren. Sie
können irgendeinen anfänglichen Teil des Commits nehmen, der lange genug
ist, um den Commit zu identifizieren:

-------------------------------------
$ git show c82a22c39c   # die ersten paar Zeichen des Namens
                        # reichen normalerweise
$ git show HEAD         # die Spitze des aktuellen Zweiges
$ git show experimentell        # die Spitze des "experimentell"-Zweiges
-------------------------------------

Jeder Commit hat normalerweise einen "Eltern" (parent)-Commit,
welcher auf den vorherigen Status des Projekts zeigt:

-------------------------------------
$ git show HEAD^  # um den Eltern-Commit von HEAD zu sehen
$ git show HEAD^^ # um den Grosseltern-Commit von HEAD zu sehen
$ git show HEAD~4 # um den Urgrosseltern-Commit von HEAD zu sehen
-------------------------------------

Beachten Sie, dass zusammengeführte Commits mehr als einen
Eltern-Commit besitzen können:

-------------------------------------
$ git show HEAD^1 # Den ersten Eltern-Commit von HEAD (das Selbe wie HEAD^) einsehen
$ git show HEAD^2 # Den zweiten Eltern-Commit von HEAD einsehen
-------------------------------------

Sie können auch selbst Commits namen geben; nach

-------------------------------------
$ git tag v2.5 1b2e1d63ff
-------------------------------------

Können Sie auf 1b2e1d63ff mit dem Namen "v2.5" referenzieren. Falls
Sie diesen Namen mit anderen teilen möchten (zum Beispiel, um eine
Releaseversion zu identifizieren), sollten Sie ein "tag"-Objekt erstellen
und es eventuell noch signieren; siehe linkgit:git-tag[1] für Details.

Jeder Git-Befehl der einen Commit wissen möchte, kann jeden dieser
Namen verwenden. Beispiel:

-------------------------------------
$ git diff v2.5 HEAD     # den akutellen HEAD mit v2.5 vergleichen
$ git branch stable v2.5 # Einen neuen Zweig mit Namen "stable" auf
                         # Basis von v2.5 erzeugen
$ git reset --hard HEAD^ # Den aktuellen Zweig und das aktuelle Arbeitsverzeichnis
                         # zurücksetzen auf seinen Status in HEAD^
-------------------------------------

Seien Sie vorsichtig mit dem vorherigen Kommando: Zusätzlich zum verlieren
aller Änderungen im aktuellen Arbeitsverzeichnis, werden auch noch
alle späteren Commits dieses Zweigs gelöscht. Wenn dieser Zweig
der einzige ist welcher diese Commits enthält, gehen diese verloren.
Ausserdem, benutzen Sie 'git-reset' nicht auf einem öffentlich
einsehbaren Zweig von der andere Entwickler ziehen, da es sinnlose
Zusammenführungen erzwingt und die Geschichte gesäubert werden muss.
Falls Sie irgendwelche Änderungen rückgängig machen müssen, die
Sie versendet haben, sollten Sie stattdessen 'git-revert' benutzen.

Der Befehl 'git-grep' kann nach Strings in einer beliebigen Version
Ihres Projektest suchen, also sucht

-------------------------------------
$ git grep "hallo" v2.5
-------------------------------------

nach allen Vorkommnissen von "hallo" in v2.5.

Falls Sie den Namen des Commits nicht angeben sucht 'git-grep' in
den Dateien in ihrem aktuellen Arbeitsverzeichnis.

-------------------------------------
$ git grep "hello"
-------------------------------------

ist also ein einfacher Weg, nur die Dateien zu durchsuchen, die
git verwaltet.

Viele git-Befehle können auch mehrere Commits als Argumente annehmen,
welche verschieden ausgedrückt werden können. Hier einige Beispiele
mit 'git-log':

-------------------------------------
$ git log v2.5..v2.6            # Commits zwischen v2.5 und v2.6
$ git log v2.5..                # Commits seit v2.5
$ git log --since="2 weeks ago" # Commits der letzten 2 Wochen
$ git log v2.5.. Makefile       # Commits seit v2.5 in welchen
                                # Makefile bearbeitet wurde
-------------------------------------

Sie können 'git-log' auch einen "Bereich" (range) von Commits angeben,
wovon der Erste nicht unbeding ein Vorfahre des Zweiten sein muss;
zum Beispiel, wenn die Spitzen der Zweige "stabil" und "experimentell"
sich getrennt haben von einem gemeinsamen Commit, dann zeigt

-------------------------------------
$ git log stabil..experimentell
-------------------------------------

die Commits an, die im Zweig "experimentell" aber nicht im Zweig
"stabil" getätigt wurden. Dagegen zeigt

-------------------------------------
$ git log experimentell..stabil
-------------------------------------

die Commits an, die im Zweig "stabil" aber nicht im Zweig
"experimentell" vorgenommen wurden.

Das 'git-log'-Kommando hat eine Schwäche: Es muss Commits in einer
Liste anzeigen. Wenn die Geschichte Entwicklungszweige enthält,
die sich getrennt und wieder zusammengeführt haben, ist die Reihenfolge,
in welcher 'git-log' die Commits anzeigt, bedeutungslos.

Die meisten Projekte mit mehreren Mitwirkenden (wie der Linuxkernel
oder git selbst) haben häufige Zusammenführungen. 'gitk' funktioniert
in diesem Falle besser, um die Projektgeschichte zu visualisieren.
Beispielsweise

-------------------------------------
$ gitk --since="2 weeks ago" treiber/
-------------------------------------

erlaubt Ihnen, die Commits der letzten zwei Wochen im "treiber"-Verzeichnis
durchzusehen (Hinweis: Sie können die Schriften von gitk anpassen,
indem Sie die Strg- oder die Control-Taste gedrückt halten und "+" oder
"-" drücken).

Die meisten Befehle, die Dateinamen als Argumente akzeptieren, erlauben
Ihnen optional auch einen Commit dem Dateinamen voranzustellen, um
eine bestimmte Version der Datei anzugeben:

-------------------------------------
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------

Sie können auch 'git-show' verwenden, um eine solche Datei einzusehen:

-------------------------------------
$ git show v2.5:Makefile
-------------------------------------

Nächste Schritte
----------------

Diese Anleitung sollte für grundlegende verteilte Revisionskontrolle
Ihrer Projekte reichen. Um jedoch die Tiefe und Macht von git komplett
zu verstehen, müssen Sie zwei einfache Ideen verstehen, auf welchen
git basiert:

  * Die Objektdatenbank ist die eher elegante Methode, um die
    Geschichte ihrer Projektdateien, -verzeichnisse und -commits
    abzulegen

  * Die Indexdatei ist ein Zwischenspeicher des Status eines
    Verzeichnisbaumes, der verwendet wird, um Bereitstellungen
    zu erzeugen, Arbeitsverzeichnisse umzustellen und die verschiedenen
    in einer Zusammenführung involvierten Bäume zu behalten.

Teil zwei dieser Anleitung erklärt die Objektdatenbank, die Bereitstellung
und einige andere Kleinigkeiten die Sie benötigen um das meiste aus git
herauszuholen. Es befindet sich unter linkgit:gittutorial-2[7].

Falls Sie nicht gleich damit weiterfahren wollen, einige dieser
Exkurse können nun interessant sein:

  * linkgit:git-format-patch[1], linkgit:git-am[1]: Diese wandeln
    eine Serie von Giteintragungen in als E-Mail versandte Patches um
    und umgekehrt. Nützlich für Projekte wie den Linuxkernel, welcher
    stark auf per E-Mail versandten Patches basiert.

  * linkgit:git-bisect[1]: Falls sich ein Rückschritt im Projekt befindet,
    ein Weg, das Problem zu finden, ist das Suchen in der Geschichte um
    die exakte Eintragung zu finden, welche daran schuld ist. Git bisect
    kann Ihnen helfen, eine Binärsuche nach diesem Commit zu starten.
    Es ist clever genug, um eine fast-optimale Suche auszuführen, selbst im
    Falle einer komplexen, nicht-linearen Geschichte mit vielen
    zusammengeführten Zweigen.

  * link:everyday.html[Tägliches GIT mit 20 Befehlen oder so]

  * linkgit:gitcvs-migration[7]: Git für CVS-Benutzer.

SEE ALSO
--------
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
link:everyday.html[Tägliches git],
link:user-manual.html[The Git User's Manual]

GIT
---
Teil der linkgit:git[1] Suite.