Git

1.3 Los geht’s - Git Grundlagen

Git Grundlagen

Was also ist Git, in kurzen Worten? Es ist wichtig, den folgenden Abschnitt zu verstehen, in dem es um die grundlegenden Konzepte von Git geht. Das wird Sie in die Lage versetzen, Git einfacher und effektiver anzuwenden. Versuchen Sie Ihr vorhandenes Wissen über andere Versionsverwaltungssysteme, wie Subversion oder Perforce, beiseite zu schieben, während Sie Git kennenlernen. Wenn Sie diesen Ratschlag befolgen, wird es Ihnen an vielen Stellen leichter fallen und die feinen Unterschiede zu anderen Versionsverwaltungssysteme werden Sie nicht so einfach durcheinanderbringen. Git speichert und verwaltet Information deutlich anders als andere Systeme, auch wenn die Benutzerschnittstelle relativ ähnlich wirkt. Diese Unterschiede zu verstehen wird Ihnen helfen, Verwirrung bei der Anwendung von Git zu vermeiden.

Snapshots und nicht die Unterschiede

Der Hauptunterschied zwischen Git und anderen Versionsverwaltungssystemen (insbesondere auch Subversion und vergleichbare Systeme) besteht in der Art und Weise wie Git die Daten betrachtet. Die meisten anderen Systeme speichern Information, als eine fortlaufende Liste von Änderungen an Dateien (es werden die Unterschiede gesammelt und gespeichert). Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen, die sie verwalten, als eine Menge von Dateien und die Änderungen, die über die Zeit hinweg an einzelnen Dateien vorgenommen werden.

Storing data as changes to a base version of each file.
Figure 4. Speichern von Daten als Änderung an einzelnen Dateien auf Basis einer Ursprungsdatei.

Git arbeitet nicht auf diese Art und Weise. Stattdessen betrachtet Git seine Daten eher als eine Reihe von Snapshots eines Mini-Dateisystems. Jedes Mal, wenn Sie committen, das heißt den gegenwärtigen Status Ihres Projekts als eine Version in Git speichern, sichert Git den Zustand sämtlicher Dateien in diesem Moment und macht sozusagen ein Schnappschuss (engl. Snapshot) von all Ihren Daten. Zusätzlich speichert Git eine Referenz auf diesen Snapshot. Um dies möglichst effizient und schnell tun zu können, kopiert Git unveränderte Dateien nicht, sondern legt lediglich eine Verknüpfung zu der vorherigen Version der Datei an. Das folgende Bild soll diese Vorgehensweise verdeutlichen.

Git stores data as snapshots of the project over time.
Figure 5. Git speichert die Daten-Historie eines Projekts in Form von Snapshots.

Dies ist ein wichtiger Unterschied zwischen Git und praktisch allen anderen Versionsverwaltungssystemen. In Git wurden daher fast alle Aspekte der Versionsverwaltung neu überdacht, die in anderen Systemen mehr oder weniger von ihrer jeweiligen Vorgängergeneration übernommen worden waren. Git arbeitet im Großen und Ganzen eher wie ein mit einigen unglaublich mächtigen Werkzeugen ausgerüstetes Mini-Dateisystem, statt nur als Versionsverwaltungssystem. Auf einige der Vorteile, die es mit sich bringt, Daten in dieser Weise zu verwalten, werden wir in Kapitel Git Branching eingehen, wenn wir das Git Branching Konzept kennenlernen.

Fast jede Funktion arbeitet lokal

Die meisten Befehle in Git benötigen nur die lokalen Dateien und Ressourcen auf einem PC, um zu funktionieren. In erster Linie werden keine Informationen von einem anderen Rechner im Netzwerk benötigt. Wenn Sie bisher mit einem CVCS gearbeitet haben, das für die meisten Operationen einen langsamen Netzwerkzugriff benötigt hat, dann wird dieser Aspekt Sie im Glauben lassen, dass Ihr PC auf einmal mit Lichtgeschwindigkeit ausgestattet wurde. Die allermeisten Operationen können nahezu ohne jede Verzögerung ausgeführt werden, da die vollständige Historie eines Projekts bereits auf dem jeweiligen Rechner verfügbar ist.

Um beispielsweise die Historie des Projekts zu durchsuchen, braucht Git sie nicht von einem externen Server zu holen – es liest diese einfach aus der lokalen Datenbank. Das heißt, die vollständige Projekthistorie ist ohne jede Verzögerung verfügbar. Wenn man sich die Änderungen einer aktuellen Version einer Datei im Vergleich zu vor einem Monat, anschauen möchte, dann kann Git den Stand von vor einem Monat in der lokalen Historie nachschlagen und einen lokalen Vergleich zur vorliegenden Datei durchführen. Für diesen Anwendungsfall benötigt Git keinen externen Server, weder um Dateien dort nachzuschlagen, noch um Unterschiede dort bestimmen zu lassen.

Dies bedeutet natürlich außerdem, dass es fast nichts gibt, was man nicht tun kann, nur weil man gerade offline ist oder keinen Zugriff auf ein VPN hat. Wenn man also gerade im Flugzeug oder Zug ein wenig arbeiten will, kann man problemlos seine Arbeit einchecken und dann wenn man wieder mit einem Netzwerk verbunden ist, die Dateien auf einen Server hochladen. Wenn man zu Hause sitzt, aber der VPN Client gerade mal wieder nicht funktioniert, kann man immer noch arbeiten. Bei vielen anderen Systemen wäre dies unmöglich oder äußerst kompliziert umzusetzen. Wenn man zum Beispiel mit Perforce arbeitet, kann man nicht sonderlich viel tun, solange man nicht mit dem Server verbunden ist. In Subversion und CVS kann man in diesem Fall zwar Dateien bearbeiten, aber das Einchecken der Daten ist nicht möglich, da der entsprechende Server und damit auch die Datenbank offline sind. Das mag auf den ersten Blick nicht nach einem großen Problem aussehen, aber Sie werden überrascht sein, was für einen großen Unterschied das ausmachen kann.

Git stellt Integrität sicher

Von allen zu speichernden Daten berechnet Git Prüfsummen (engl. checksum) und speichert diese als Referenz zusammen mit den Daten ab. Das macht es unmöglich, dass sich Inhalte von Dateien oder Verzeichnissen ändern, ohne dass Git das mitbekommt. Git basiert auf dieser Funktionalität und sie ist ein integraler Teil der Git Philosophie. Man kann Informationen deshalb z.B. nicht während der Übermittlung verlieren oder unwissentlich beschädigte Dateien verwenden, ohne dass Git in der Lage wäre, dies festzustellen.

Der Mechanismus, den Git verwendet, um diese Prüfsummen zu erstellen, heißt SHA-1 Hash. Eine solche Prüfsumme ist eine 40 Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen (0-9 und a-f) besteht und wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur berechnet. Ein SHA-1 Hash sieht wie folgt aus:

24b9da6552252987aa493b52f8696cd6d3b00373

Dieses Hashes begegnen einem überall bei der Arbeit, weil sie so ausgiebig von Git genutzt werden. Git speichert sogar alle Informationen in der Datenbank auf Basis dieser Hashes. Statt eine Datei über den Dateinamen zu referenzieren, verwendet Git den Hash dafür.

Git hängt normalerweise nur Daten an, und löscht sie nicht

Fast alle in Git verfügbaren Befehle, fügen Daten jeweils nur zur internen Git Datenbank hinzu und entfernen keine Daten aus der Datenbank. Deshalb ist es sehr schwer, das System dazu zu bewegen, irgendetwas zu tun, das nicht wieder rückgängig zu machen ist, oder dazu, Daten in irgendeiner Form zu löschen. Wie in jedem anderen VCS, kann man in Git Daten verlieren oder durcheinander bringen, solange man sie noch nicht eingecheckt hat. Aber sobald man einen Schnappschuss in Git eingecheckt hat, ist es sehr schwierig, diese Daten wieder zu verlieren, insbesondere wenn man regelmäßig seine lokale Datenbank auf ein anderes Repository hochlädt.

Unter anderem deshalb macht es so viel Spaß mit Git zu arbeiten. Man weiß genau, man kann ein wenig experimentieren, ohne befürchten zu müssen, irgendetwas zu zerstören oder durcheinander zu bringen. Wer sich genauer dafür interessiert, wie Git Daten speichert und wie man Daten, die scheinbar verloren sind, wiederherstellen kann, dem wird das Kapitel Undoing Things ans Herz gelegt.

Die drei Zustände

Jetzt heißt es aufgepasst. Es folgt die wichtigste Information, die man sich merken muss, wenn man Git erlernen und dabei Fallstricke vermeiden will. Git definiert drei Hauptzustände, in denen sich eine Datei befinden kann: Committet (engl. committed), geändert (engl. modified) und für Commit vorgemerkt (engl. staged). Committet bedeutet, dass die Daten sicher in der lokalen Datenbank gespeichert sind. Geändert bedeutet, dass eine Datei geändert, aber noch nicht in die lokale Datenbank eingecheckt wurde. Für Commit vorgemerkt bedeutet, dass eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt ist.

<<<<<<< HEAD Das führt uns zu den drei Hauptbereichen eines Git Projektes: das Git Verzeichnis, das Arbeitsverzeichnis und die sogenannte Staging-Area.

Working directory, staging area, and Git directory.
Figure 6. Arbeitsverzeichnis, Staging-Area und Git Verzeichnis.

This leads us to the three main sections of a Git project: the Git directory, the working tree, and the staging area.

Working tree, staging area, and Git directory.
Figure 7. Working tree, staging area, and Git directory.

>>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

Das Git Verzeichnis ist der Ort, an dem Git Metadaten und die lokale Datenbank für ein Projekt sichert. Dies ist der wichtigste Teil von Git, und dieser Teil wird kopiert, wenn man ein Repository von einem anderen Rechner klont.

<<<<<<< HEAD Das Arbeitsverzeichnis ist ein einzelnes Abbild einer spezifischen Version des Projektes. Die dort enthaltenen Dateien werden aus der komprimierten Datenbank geholt und auf der Festplatte in einer Form gespeichert, sodass man sie nutzen oder bearbeiten kann.

The working tree is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

Die Staging Area ist einfach eine Datei, normalerweise befindet sich diese im Git Verzeichnis, in der vorgemerkt wird, welche Änderungen der nächste Commit umfassen soll. Manchmal wird dieser Ort auch als “Index” bezeichnet, aber der Begriff Staging-Area ist der gängigere.

Die grundlegenden Arbeitsschritte beim Einchecken sind in etwa folgende:

<<<<<<< HEAD 1. Man ändert die zu bearbeitenden Dateien im Arbeitsverzeichnis 2. Man merkt die Dateien für einen Commit vor, fügt also einen Schnappschuss der Dateien der Staging-Area hinzu 3. Man führt einen Commit aus, wodurch der in der Staging-Area vorgemerkte Schnappschuss dauerhaft im Git Verzeichnis gespeichert wird

Wenn eine bestimmte Version einer Datei im Git Verzeichnis liegt, gilt sie als committet, oder anders ausgedrückt, sie gilt als eingecheckt (engl. committed). Wenn sie geändert und in die Staging-Area hinzugefügt wurde, gilt sie als für den Commit vorgemerkt (engl. staged). Und wenn sie geändert, aber noch nicht zur Staging-Area hinzugefügt wurde, gilt sie als geändert (engl. modified). Im Kapitel [_git_basics_chapter] werden diese drei Zustände noch näher erläutert und wie man diese sinnvoll einsetzen kann oder alternativ, wie man den Zwischenschritt der Staging-Area überspringen kann.

  1. You modify files in your working tree.

  2. You stage the files, adding snapshots of them to your staging area.

  3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

If a particular version of a file is in the Git directory, it’s considered committed. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In [_git_basics_chapter], you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

=== Kommandozeile

Es gibt viele verschiedene Möglichkeiten Git einzusetzen. Auf der einen Seite gibt es die Werkzeuge, die per Kommandozeile bedient werden und auf der anderen, die vielen grafischen Benutzeroberflächen (engl. graphical user interface, GUI), die sich im Leistungsumfang unterscheiden. In diesem Buch verwenden wir die Kommandozeile. In der Kommandozeile können nämlich wirklich alle vorhandenen Git Befehle ausgeführt werden. Bei den meisten grafischen Oberflächen ist dies nicht möglich, da aus Gründen der Einfachheit nur ein Teil der Git Funktionalitäten zur Verfügung gestellt werden. Wenn Sie sich in der Kommandozeilenversion von Git auskennen, finden Sie sich wahrscheinlich auch in einer GUI-Version relativ schnell zurecht, aber andersherum muss das nicht unbedingt zutreffen. Außerdem ist die Wahl der grafischen Oberfläche eher Geschmackssache, wohingegen die Kommandozeilenversion auf jedem Rechner installiert und verfügbar ist.

In diesem Buch gehen wir deshalb davon aus, dass Sie wissen, wie man bei einem Mac ein Terminal öffnet, oder wie man unter Windows die Eingabeaufforderung oder die Powershell öffnet. Sollten Sie jetzt nur Bahnhof verstehen, sollten Sie an dieser Stelle abbrechen und sich schlau machen, was ein Terminal bzw. Eingabeaufforderung ist und wie man diese bedient. Nur so ist sichergestellt, dass Sie unseren Beispielen und Ausführungen im weiteren Verlauf des Buches folgen können.

=== Git installieren

Bevor man mit Git loslegen kann, muss man es natürlich als aller erstes installieren. Auch wenn es vielleicht bereits auf dem Rechner installiert ist, sollte man sicherstellen, dass die aktuellste Version vorhanden ist. Es gibt verschiedene Möglichkeiten Git zu installieren. Man kann es entweder als fertiges Paket oder über ein Installationsprogramm installieren, oder alternativ den Quellcode herunterladen und selbst kompilieren.

Note

<<<<<<< HEAD Die Beispiele aus diesem Buch basieren alle auf Git in der Version 2.0.0. Auch wenn die meisten Befehle, die wir anwenden werden, auch in älteren Versionen funktionieren, kann es doch sein, dass die Befehlsausgabe oder das Verhalten leicht anders ist. Da in Git sehr auf Abwärtskompatibilität geachtet wird, sollten aber alle neueren Versionen nach der Version 2.0 genauso gut funktionieren.

This book was written using Git version 2.0.0. Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you’re using an older version. Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

==== Installation unter Linux

<<<<<<< HEAD Wenn man Git unter Linux mit einem Installationsprogramm installieren will, kann man das normalerweise mit dem Paketmanager, der jeweiligen Distribution tun. Unter Fedora zum Beispiel, kann man dazu yum verwenden:

If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora for example, you can use yum: >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

$ sudo yum install git-all

Auf einem Debian-basierten System, wie Ubuntu, steht apt-get zur Verfügung:

$ sudo apt-get install git-all

Auf der Git Homepage http://git-scm.com/download/linux findet man weitere Möglichkeiten und Optionen, wie man Git unter einem Unix-basierten Betriebssystem installieren kann.

==== Installation unter Mac OS X

Auch beim Mac gibt es verschiedene Wege um Git zu installieren. Der einfachste ist wahrscheinlich, die Xcode Kommandozeilenwerkzeuge zu installieren. Bei Mavericks (10.9) oder neueren Versionen kann man dazu einfach git im Terminal eingeben. Wenn Git noch nicht installiert ist, erscheint eine Abfrage, ob man es installieren möchte.

Wenn man eine sehr aktuelle Version einsetzen möchte, kann man Git auch über ein Installationsprogramm installieren. Auf der Git Homepage http://git-scm.com/download/mac findet man die jeweils aktuellste Version und kann sie von dort herunterladen.

Git OS X installer.
Figure 8. Git OS X Installationsprogramm.

Ein weitere Möglichkeit ist es, GitHub for Mac zu installieren. Es gibt dort eine Option, dass man neben der grafischen Oberfläche auch gleich die Kommandozeilen Werkzeuge mit installieren kann. GitHub for Mac kann man unter http://mac.github.com herunterladen.

==== Installation unter Windows

<<<<<<< HEAD Auch für Windows gibt es einige, wenige Möglichkeiten zur Installation von Git. Eine offizielle Windows Version findet man direkt auf der Git Homepage. Gehen Sie dazu auf http://git-scm.com/download/win und der Download sollte dann automatisch starten. Man sollte dabei beachten, dass es sich hierbei um das Projekt Git for Windows handelt (auch msysGit genannt), welches unabhängig von Git selbst ist. Weitere Informationen hierzu finden Sie unter http://msysgit.github.io/.

There are also a few ways to install Git on Windows. The most official build is available for download on the Git website. Just go to http://git-scm.com/download/win and the download will start automatically. Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://git-for-windows.github.io/.

To get an automated installation you can use the Git Chocolatey package. Note that the Chocolatey package is community maintained. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

Eine weitere Möglichkeit ist es, GitHub for Windows zu installieren. Das Installationsprogramm enthält neben der GUI, auch eine Kommandozeilenversion von Git. Diese funktioniert zusammen mit der Powershell tadellos, und richtet die wichtigsten Berechtigungs-Caching- (engl. credential caching) und Zeilenenden-Konfigurationen (CRLF) vorab ein. Was es damit genau auf sich hat, werden Sie erst später verstehen. Erst mal reicht es aus, dass Sie wissen, dass sie so etwas haben wollen. Sie können das ganze Paket von der GitHub for Windows Homepage unter http://windows.github.com herunterladen.

<<<<<<< HEAD ==== Vom Quellcode aus installieren

Viele Leute kompilieren Git auch auf ihrem eigenen Rechner, weil sie damit, die jeweils aktuellste Version erhalten. Die vorbereiteten Pakete hinken meist ein wenig hinterher. Heutzutage ist dies nicht mehr ganz so schlimm, da Git einen gewissen Reifegrad erfahren hat.

Um Git zu installieren, benötigt man die folgenden Bibliotheken, die von Git verwendet werden: curl, zlib, openssl, expat und libiconv. Wenn auf dem System yum (z.B. auf Fedora) oder apt-get (z.B auf allen Debian-basierten System) zur Verfügung steht, kann man folgende Befehle verwenden, um diese Abhängigkeiten zu installieren:

==== Installing from Source

Some people may instead find it useful to install Git from source, because you’ll get the most recent version. The binary installers tend to be a bit behind, though as Git has matured in recent years, this has made less of a difference.

If you do want to install Git from source, you need to have the following libraries that Git depends on: autotools, curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries: >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

$ sudo yum install dh-autoreconf curl-devel expat-devel gettext-devel \
  openssl-devel perl-devel zlib-devel
$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
  gettext libz-dev libssl-dev

In order to be able to add the documentation in various formats (doc, html, info), these additional dependencies are required (Note: users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to enable the EPEL repository to download the docbook2X package):

$ sudo yum install asciidoc xmlto docbook2X
$ sudo apt-get install asciidoc xmlto docbook2x

<<<<<<< HEAD Um die Dokumentation in verschiedenen Formaten (doc, html, info) zu erstellen, sind weitere Abhängigkeiten notwendig:

Additionally, if you’re using Fedora/RHEL/RHEL-derivatives, you need to do this >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi

due to binary name differences.

<<<<<<< HEAD Wenn man alle notwendigen Abhängigkeiten installiert hat, kann man sich als nächstes die jeweils aktuellste Version als Tarball von verschiedenen Stellen herunterladen.

Man findet die Quellen auf der Kernel.org Website unter https://www.kernel.org/pub/software/scm/git, oder gespiegelt auf der GitHub Website unter https://github.com/git/git/releases. Auf der GitHub Homepage ist es einfacher herauszufinden, welches die jeweils aktuellste Version ist. Auf kernel.org hingegen werden auch Signaturen, zur Verifikation des Downloads, der jeweiligen Pakete zur Verfügung gestellt.

When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. You can get it via the Kernel.org site, at https://www.kernel.org/pub/software/scm/git, or the mirror on the GitHub website, at https://github.com/git/git/releases. It’s generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

Nachdem man sich die Quellen also beschafft hat, kann man Git kompilieren und installieren:

$ tar -zxf git-2.0.0.tar.gz
$ cd git-2.0.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info

Jetzt nachdem Git installiert ist, kann man sich Git Updates auch per Git beschaffen:

<<<<<<< HEAD $ git Uclone git://git.kernel.org/pub/scm/git/git.git

$ git clone git://git.kernel.org/pub/scm/git/git.git

>>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

=== Git Basis-Konfiguration

Nachdem Git jetzt auf Ihrem System installiert ist, sollte Sie Ihre Git Konfiguration noch anpassen. Dies muss nur einmalig auf dem jeweiligen System durchgeführt werden. Die Konfiguration bleibt bestehen, wenn Sie Git auf eine neuere Version aktualisieren. Die Git Konfiguration kann auch jederzeit geändert werden, indem die nachfolgenden Befehle einfach noch einmal ausgeführt werden.

Git umfasst das Werkzeug git config, welches die Möglichkeit bietet, Konfigurationswerte zu verändern. Auf diese Weise können Sie anpassen, wie Git aussieht und arbeitet. Die Konfiguration ist an drei verschiedenen Orten gespeichert:

  1. Die Datei /etc/gitconfig enthält Parameter, die für jeden Anwender des Systems und alle Projekte gelten. Wenn man git config mit der Option --system verwendet, wird von dieser Datei gelesen bzw. in diese Datei geschrieben.

  2. Die Werte in der Datei ~/.gitconfig gelten ausschließlich für den jeweiligen Benutzer. Wenn man git config mit der Option --global verwendet, wird von dieser Datei gelesen bzw. in diese Datei geschrieben.

  3. Die Datei config im Git Verzeichnis (also `.git/config) enthält Parameter, die für das jeweilige Projekt gelten.

Diese drei Dateien haben unterschiedliche Prioritäten. Die oberste Priorität haben die Werte aus .git/config, dann folgt ~/.gitconfig und zuletzt /etc/gitconfig. Ist zum Beispiel ein Parameter in .git/config und /etc/gitconfig mit unterschiedlichen Werten gesetzt, so gilt in diesem Fall der höherpriore Wert aus der Datei .git/config.

<<<<<<< HEAD Auf Windows Systemen sucht Git nach der Datei .gitconfig im $HOME Verzeichnis (Normalerweise zeigt $HOME bei den meisten Systemen auf C:\Users\$USER). Git schaut auch immer nach /etc/gitconfig, auch wenn dieses relativ zu dem MSys Wurzelverzeichnis ist, welches das ist, wohin man Git bei der Installation in Windows installiert hat.

On Windows systems, Git looks for the .gitconfig file in the $HOME directory (C:\Users\$USER for most people). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. If you are using version 2.x or later of Git for Windows, there is also a system-level config file at C:\Documents and Settings\All Users\Application Data\Git\config on Windows XP, and in C:\ProgramData\Git\config on Windows Vista and newer. This config file can only be changed by git config -f <file> as an admin. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

==== Ihre Identität

<<<<<<< HEAD Nachdem Sie Git installiert haben, sollten Sie als aller erstes Ihren Namen und E-Mail Adresse in Git konfigurieren. Das ist wichtig, weil Git diese Information für jeden Commit, der von Ihnen angelegt wird, hinterlegt. Diese Daten sind unveränderlich mit in Ihren erstellten Commits integriert:

The first thing you should do when you install Git is to set your user name and email address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you start creating: >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

<<<<<<< HEAD Wie schon erwähnt, brauchen Sie diese Konfiguration nur einmal vorzunehmen, wenn Sie die Option --global verwenden. Auf Grund der oben erwähnten Prioritäten gilt diese dann für all Ihre Projekte. Wenn Sie für ein spezielles Projekt einen anderen Namen oder eine andere E-Mail Adresse verwenden möchten, können Sie den Befehl ohne die --global Option innerhalb des Projektes ausführen.

Again, you need to do this only once if you pass the --global option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or email address for specific projects, you can run the command without the --global option when you’re in that project. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

Viele der grafischen Oberflächen helfen einem bei diesem Schritt, wenn man sie zum allerersten mal startet.

==== Texteditor

<<<<<<< HEAD Nachdem Sie Ihre Identität konfiguriert haben, können Sie als nächstes einstellen, welchen Texteditor Git in Situationen verwenden soll, in denen Sie einen Text oder Nachricht eingeben müssen. Normalerweise verwendet Git den Standard-Texteditor des jeweiligen Systems – das ist üblicherweise Vim. Wenn Sie einen anderen Texteditor, z.B. Emacs, verwenden wollen, können Sie das wie folgt festlegen:

Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. If not configured, Git uses your system’s default editor.

If you want to use a different text editor, such as Emacs, you can do the following: >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

$ git config --global core.editor emacs

While on a Windows system, if you want to use a different text editor, such as Notepad++, you can do the following:

On a x86 system

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"

On a x64 system

$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"

Vim, Emacs and Notepad++ are popular text editors often used by developers on Unix based systems like Linux and OS X or a Windows system. If you are not familiar with either of these editors, you may need to search for specific instructions for how to set up your favorite editor with Git.

<<<<<<< HEAD Auf Unix basierten Betriebssystemen, wie Linux und Mac, verwenden Entwickler häufig die weit verbreiteten Texteditoren Vim und Emacs. Wenn Sie sich in beiden Editoren nicht auskennen oder mit einem Windowssystem arbeiten, müssen Sie vielleicht ein wenig suchen, wie man Ihren favorisierten Texteditor für Git konfiguriert. Im Internet oder in der Hilfe Ihres Editors finden Sie bestimmt eine Hilfestellung. Wenn Sie Git nicht so konfigurieren, dass es Ihren Texteditor verwendet und Sie keine Ahnung davon haben, wie man Vim oder Emacs benutzt, werden Sie ein wenig überfordert sein, wenn diese zum ersten Mal von Git gestartet werden.

You may find, if you don’t setup an editor like this, you will likely get into a really confusing state when they are launched. Such example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit. >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

==== Einstellungen überprüfen

Wenn Sie Ihre persönlichen Einstellungen überprüfen wollen, können Sie mit dem Befehl git config --list alle Einstellungen anzeigen lassen, die Git an dieser Stelle (z.B. innerhalb eines bestimmten Projektes) bekannt sind:

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

Manche Parameter werden möglicherweise mehrfach aufgelistet, weil Git denselben Parameter in verschiedenen Dateien (z.B. /etc/gitconfig und ~/.gitconfig) gefunden hat. In diesem Fall verwendet Git dann den jeweils zuletzt aufgelisteten Wert.

Außerdem können Sie mit dem Befehl git config <key> prüfen, welchen Wert Git für einen bestimmten Parameter verwendet:

$ git config user.name
John Doe

=== Hilfe finden

Falls Sie einmal Hilfe bei der Anwendung von Git benötigen, gibt es drei Möglichkeiten, die entsprechende Seite aus der Dokumentation (engl. manpage) für jeden Git Befehl anzuzeigen:

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

Beispielweise erhalten Sie die Hilfeseite für den git config Befehl folgendermaßen:

$ git help config

Diese Befehle sind nützlich, weil Sie sich die Hilfe jederzeit anzeigen lassen können, auch wenn Sie einmal offline sind. Wenn die Hilfeseiten und dieses Buch nicht die gesuchten Antworten bringen, können Sie Ihr Glück in den Räumen #git oder #github auf dem Freenode IRC Server (irc.freenode.net) versuchen. Diese Räume sind in der Regel sehr gut besucht. Normalerweise findet sich unter den vielen Anwendern, die oft sehr viel Erfahrung mit Git haben, irgendjemand, der Ihnen weiterhelfen kann.

=== Zusammenfassung

Sie sollten jetzt ein grundlegendes Verständnis davon haben, was Git ist und wie es sich von einer zentralisierten Versionsverwaltung unterscheidet, welche Sie früher vielleicht schon einmal verwendet haben. Außerdem sollte Ihr Rechner nun eingerichtet und mit einem persönlichen Profil versehen sein, um mit Git loslegen zu können. Jetzt ist es an der Zeit, auf einige Git Grundlagen einzugehen.

== Git Grundlagen

Wenn Sie nur wenig Zeit haben um Git zu erlernen, dann sollten Sie sich dieses Kapitel zu Gemüte führen. In diesem Kapitel werden die grundlegenden Git Befehle erklärt, die Sie für den Großteil der täglichen Arbeit mit Git brauchen. Am Ende des Kapitels sollten Sie in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zu versionieren bzw. aus der Versionsverwaltung zu entfernen, Dateien in die Staging-Area hinzuzufügen und schließlich einen Commit durchzuführen. Außerdem wird gezeigt, wie Sie Git so konfigurieren können, dass es bestimmte Dateien und Dateimuster ignoriert, wie Sie Fehler schnell und einfach rückgängig machen, wie Sie die Historie eines Projekts durchsuchen und Änderungen zwischen Commits nachschlagen, und wie Sie von einem Remote-Repository Daten herunter- bzw. dort hochladen können.

=== Ein Git Repository anlegen

Sie haben zwei Möglichkeiten, ein Git Repository auf Ihrem Rechner anzulegen. Sie können entweder ein existierendes Projekt oder Verzeichnis in ein neues Git Repository importieren. Oder Sie können ein existierendes Repository von einem Server auf den eigenen Rechner klonen.

==== Ein existierendes Verzeichnis als Git Repository initialisieren

<<<<<<< HEAD Wenn Sie ein bestehendes Projekt in Zukunft versionieren möchten, können Sie dazu in das Hauptverzeichnis des Projekts wechseln und den folgenden Befehl ausführen:

If you’re starting to track an existing project in Git, you need to go to the project’s directory. If you’ve never done this, it looks a little different depending on which system you’re running:

for Linux:

$ cd /home/user/your_repository

for Mac:

$ cd /Users/user/your_repository

for Windows:

$ cd /c/user/your_repository

and type: >>>>>>> 811dffebd4ff1348819f8acc70f954bd4ad65057

$ git init

Der Befehl erzeugt ein Unterverzeichnis .git, in dem alle relevanten Git Repository Daten enthalten sind, also ein Git Repository Grundgerüst. Zu diesem Zeitpunkt werden noch keine Dateien in Git versioniert. (Im Kapitel [_git_internals] finden Sie weitere Informationen, welche Dateien im .git Verzeichnis enthalten sind und was ihre Aufgabe ist.)

Wenn Sie bereits existierende Dateien versionieren möchten (und es sich nicht nur um ein leeres Verzeichnis handelt), dann sollten Sie den aktuellen Stand in einem initialen Commit einchecken. Mit dem Befehl git add legen Sie fest, welche Dateien versioniert werden sollen und mit dem Befehl git commit erzeugen Sie einen neuen Commit:

$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'

Wir werden gleich noch einmal genauer auf diese Befehle eingehen. Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git Repository erzeugt und einen ersten Commit angelegt haben.

Ein existierendes Repository klonen

Wenn Sie eine Kopie eines existierenden Git Repositorys anlegen wollen - z.B. um an einem Projekt mitzuarbeiten - können Sie den Befehl git clone verwenden. Wenn Sie bereits Erfahrung mit einem anderen VCS System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl clone und nicht etwa checkout lautet. Dies ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten - Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner. Mit git clone wird jede einzelne Version jeder einzelnen Datei, also die gesamte Historie eines Projekts auf den Rechner heruntergeladen. Wenn ein Repository auf einem Server einmal beschädigt wird (z.B. weil die Festplatte beschädigt wird), kann man tatsächlich jeden beliebigen Klon des Repositorys verwenden, um das Repository auf dem Server wieder in dem Zustand wiederherzustellen, in dem es sich befand, als es geklont wurde (es kann passieren, dass man einige auf dem Server vorhandene Hooks verliert, aber alle versionierten Daten bleiben erhalten. Im Kapitel Git on the Server erfahren Sie dazu nähere Details).

Sie können ein Repository mit dem Befehl git clone [url] klonen. Um beispielsweise das Repository der linkbaren Git Bibliothek libgit2 zu klonen, führen Sie den folgenden Befehl aus:

$ git clone https://github.com/libgit2/libgit2

Git legt dann ein Verzeichnis “libgit2” an, initialisiert in diesem ein .git Verzeichnis, lädt alle Daten des Repositorys herunter, und checkt eine Arbeitskopie der aktuellsten Version aus. Wenn Sie in das neue libgit2 Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich mit ihnen loslegen. Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als “libgit2” klonen möchten, können Sie das wie folgt durchführen:

$ git clone https://github.com/libgit2/libgit2 mylibgit

Dieser Befehl tut das gleiche wie der vorhergehende, aber das Zielverzeichnis lautet diesmal mylibgit.

Git unterstützt eine Reihe unterschiedlicher Übertragungsprotokolle. Das vorhergehende Beispiel verwendet das https:// Protokoll, aber Ihnen können auch die Angaben git:// oder user@server:path/to/repo.git begegnen, welche das SSH-Transfer-Protokoll verwenden. Im Kapitel Git on the Server gehen wir auf die verfügbaren Optionen und deren Vor- und Nachteile ein, die ein Server hat, um Zugriff auf ein Git Repository zu ermöglichen.