'''Git''' ist ein dezentrales [[Versionsverwaltung|Source-Code-Managementsystem]]. Git wurde ursprünglich für die Entwicklung des [[Linux]]-Kernels entwickelt und steht unter der GPL.

== Geschichte ==
Nachdem das alte Versionsverwaltungssystem des Linux-Kernels seine Lizenz änderte, und es dadurch für einige Entwickler nicht mehr möglich war, dieses System zu nutzen, beschloss Linus Torvalds, ein eigenes SCM zu entwickeln, da andere SCMs nicht die Anforderungen der Kernelentwickler erfüllten.

Designziel von git war es insbesondere, ein sehr schnelles Zusammenführen von Entwicklungszweigen (Merging) zu ermöglichen. Des Weiteren musste das System eine Korruption der Versionsgeschichte, zum Beispiel durch einen Festplattenschaden oder bösartigen Angriff, selbstständig erkennen. Außerdem musste es möglich sein, dass Entwickler unabhängig voneinander arbeiten. Alle diese Ziele wurden durch git verwirklicht.

== Installation ==
Die meisten Linuxdistributoren bieten git bereits in ihren Software-Archiven an. Bei einigen Distributoren steht "git" jedoch als Abkürzung für die bereits länger existierenden GNU Interactive Tools, daher kann es sein, dass das Paket "git" nicht das Versionsverwaltungssystem installiert.

* Benutzer von Ubuntu oder Debian installieren das Paket ''git-core''.
* Fedora-User können einfach das Paket ''git'' nehmen.

=== Windows ===
Für Windowsbenutzer existiert ein Port von git, der sich msysgit nennt und unter [http://code.google.com/p/msysgit/] heruntergeladen werden kann. Msysgit kommt komplett mit einer Konsole (GitBash), die sich auch in Kontextmenüs integriert, und ermöglicht so auch dem Windowsnutzer komfortables Arbeiten mit git.

== Aufbau von git ==
''TODO: Eventuell näher auf das Architekturdesign eingehen.''

Grundsätzlich ist git ein verteiltes SCM. Das heißt, dass zu einem Projekt jeder Entwickler ein eigenes lokales Projektarchiv (Repository) hat. Normalerweise werden die Archive nur lokal genutzt, aber den Entwickler hindert nichts daran, sein lokales Repository auch öffentlich einsehbar zu machen.

Git behandelt jedes Archiv unabhängig. Verbindungen zu einem Server werden nicht hergestellt, bis der Benutzer es explizit wünscht (z.B. durch die Befehle <tt>push</tt> und <tt>pull</tt>). Ein Archiv besteht aus einer Ansammlung von Patches (diffs/Deltas), die die einzelnen commits darstellen und durch eine Baumstruktur miteinander in Verhältnis stehen. Durch Hinabwandern des Baumes und Anwendung der Patches auf dem Weg kann somit der Status zum Zeitpunkt jedes einzelnen commits hergestellt werden. Verzweigungsstellen zu verschiedenen Branches sind in dieser Baumstruktur Punkte, an denen ein commit mehr als ein Kind hat, und Merges sind solche commits, die mehr als einen Vater haben.

Die einzelnen Branches sind jeweils durch einen sogenannten ''head'' markiert, der sozusagen einen Zeiger auf den letzten commit dieses Zweiges darstellt.

== Schnellstart ==
Um schnell in git einsteigen zu können, sind hier die allerwichtigsten Befehle dargestellt. Dies ist jedoch keine Anleitung, und spricht branching und merging zum Beispiel gar nicht an. Ein einfaches Tutorial gibt es (auf Englisch) auf der Git Homepage. (siehe [[Git#Weblinks|Weblinks]])

=== Archiv herunterladen (clone) ===
Um mit der Entwicklung zu beginnen, muss man zunächst natürlich seine eigene Kopie des Repositorys haben. Diese bekommt man mit dem <tt>clone</tt>-Befehl. Der Befehl ist das git-Äquivalent zum Subversion-Befehl <tt>checkout</tt>. (Achtung: Dieser Befehl existiert zwar auch in git, hat aber eine andere Aufgabe)

Da die gesamte Versionsgeschichte des Projektes heruntergeladen wird, kann dieser Befehl je nach Verbindungsgeschwindigkeit sehr lange dauern.

Beispiel (Kopie des offiziellen týndur-Archives anfordern):
<pre>
git clone git://git.tyndur.org/tyndur.git
</pre>

=== Archiv aktualisieren (pull) ===
Der Befehl <tt>pull</tt> berechnet die Änderungen zwischen dem eigenen Archiv und dem Remote-Archiv und fordert die Änderungen vom Server an. <tt>pull</tt> bezieht die Änderungen standardmäßig von dem origin-Archiv, das ist normalerweise das Archiv von dem ursprünglich geclonet wurde. Unter Subversion funktioniert der <tt>update</tt>-Befehl ähnlich.

Wenn eigene commits vorliegen, die nicht auf dem Server ist (wie es bei git eigentlich typisch ist), dann kann <tt>pull</tt> angewiesen werden, versuchen, die Änderungen in den eigenen Tree zu übernehmen, sodass nachher sowohl die lokalen, als auch die remote-commits vorliegen. Dies geht mit dem <tt>--rebase</tt>-Parameter.

Beispiel:
<pre>
# Falls der lokale Tree frei von eigenen commits ist
git pull

# Falls der Tree eigene commits enthält, die dem Server unbekannt sind
git pull --rebase
</pre>

=== Änderungen anwenden (add/commit) ===
Will man seine Änderungen am Code in einen commit packen, so muss man git zunächst mitteilen, welche Dateiänderungen wichtig sind. Das macht man mit dem <tt>add</tt>-Befehl.

Sobald man alle Dateien hinzugefügt hat, ruft man <tt>git commit</tt> auf. Es öffnet sich ein Editor, in dem man die commit-Nachricht eingibt. Man kann jedoch auch mit dem Parameter <tt>-m</tt> direkt eine Nachricht angeben.

Im Gegensatz zu den gleichbenannten Subversion-Befehlen laufen beide Befehle bei git nur lokal ab.

Beispiel:
<pre>
# Geänderte Dateien hinzufügen
git add foo.c bar.c

# Änderungen eintragen
git commit
# Oder auch so
git commit -m "Fixes bug #31415"
</pre>

=== Änderungen übertragen (push) ===
Sobald commits vorliegen, möchte man diese sicherlich an den Hauptserver übertragen und öffentlich machen. Dies macht man mit dem <tt>push</tt>-Befehl, vorausgesetzt, man hat auch Schreibzugriff. In anderen Fällen muss man meistens Patches an die Entwickler schicken (z.B. bei týndur). Git bietet dafür ebenfalls komfortable Mechanismen, die in der git-Dokumentation zu finden sind.

Zum erfolgreichen push muss der tree jedoch ein wenig mit dem auf dem Hauptserver abgestimmt sein. Vorher ist also ein <tt>git pull --rebase</tt> zu empfehlen, um Konflikte zu vermeiden.

Da bei Subversion alle Commits direkt auf den Server kommen, gibt es hier keinen vergleichbaren Befehl. Der SVN-Befehl <tt>commit</tt> vereint sozusagen die Funktionalität von Gits <tt>commit</tt> und <tt>push</tt>

Beispiel:
<pre>
# Änderungen des Servers übertragen
git pull --rebase

# Eigene Änderungen auf den Server übertragen
git push
</pre>

=== Ausblick ===
Oben werden nur sehr grundlegende Befehle genannt, die nur ein sehr begrenztes Arbeiten ermöglichen. Hier werden auch solche genannt, die oben aus Platzgründen nicht erwähnt werden, aber trotzdem sehr wichtig sind. Dieser Absatz soll ein Anreiz sein, die Befehle in der Git-Dokumentation oder mit Hilfe von <tt>man</tt> nachzuschlagen. Bei <tt>man</tt> findet man diese Befehle unter dem Namen <tt>git-<BEFEHL></tt>.

Um erstmal ein eigenes Archiv anzulegen, sollte man den Befehl <tt>init</tt> kennen. Außerdem wird man sicherlich oft die Git-Befehle <tt>diff</tt>, <tt>log</tt> und <tt>status</tt> brauchen. Um Fehler in der History zu korrigieren muss man sicher auch einmal die Befehle <tt>reset</tt> oder <tt>revert</tt> anwenden.

Sehr wichtig sind die Branching-Mechanismen. Mit den oben genannten Befehlen wäre es nur möglich auf einem Branch zu arbeiten. Davon ist grundsätzlich abzuraten; viele Projekte verbieten sogar das Arbeiten im Hauptzweig (''master''). Wichtige Branching-Befehle sind <tt>branch</tt>, <tt>merge</tt>, <tt>rebase</tt> und <tt>checkout</tt>.

Äußerst wichtig für das Aktualisieren des Trees während der täglichen Arbeit ist <tt>stash</tt>, das es ermöglicht, die Änderungen an seiner Arbeitskopie zwischenzuspeichern und einen saubere Arbeitskopie zum <tt>pull</tt>en zu bekommen.

Aber auch die bereits oben erklärten Befehle sollte man in der Dokumentation nachschauen, da alle noch interessante Parameter haben, die sicherlich zur Anwendung kommen.

== Beispiel-Konfigurationsdatei ==
git bietet die Möglichkeit, in Konfigurationsdateien einige Einstellungen dauerhaft vorzunehmen, die man sonst jedes Mal über Kommandozeilenparameter angeben müsste. Es gibt dabei zwei verschiedene Konfigurationsdateien: ~/.gitconfig gilt für alle Repositories, .git/config liegt im Verzeichnis jedes einzelnen Repositorys und gilt nur für dieses. Für die globalen Einstellungen empfiehlt sich zumindest die folgenden Optionen anzugeben (die Werte natürlich anpassen, wo nötig):
<pre>[user]
   name = Dein Name
   email = mail@dres.se
[color]
   branch = auto
   diff = auto
   status = auto
[color "branch"]
   current = yellow reverse
   local = yellow
   remote = green
[color "diff"]
   meta = yellow bold
   frag = magenta bold
   old = red bold
   new = green bold
[color "status"]
   added = yellow
   changed = green
   untracked = cyan
[sendemail]
    chainreplyto = false
    smtpserver = smtp.mail-provider.de
    smtpuser = smtpuser
[format]
    numbered = auto
[merge]
    tool = vimdiff</pre>

In der projektspezifischen Konfigurationsdatei kann man z.B. die Mailadresse einstellen, an die git-send-email seine Mails schicken soll:
<pre>[sendemail]
    to = tyndur-devel@tyndur.org</pre>

Weitere Einstellungsmöglichkeiten werden in den Manpages der einzelnen git-Befehle beschrieben.

== Tipps & Tricks ==
=== Branch im Remote-Archiv löschen ===

Über
<pre>
git push <Remote-Archiv> :heads/<Branch>
</pre>
kann der Branch <Branch> im Remote-Archiv <Remote-Archiv> (typischerweise ''origin'') gelöscht werden.

== Vergleich zu Subversion ==
Wie bei so vielen konkurrierenden Projekten gibt es auch viele Meinungen, Diskussionen und Flamewars bei der Frage, welches SCM das beste sei. Git und [[Subversion]] werden oft direkt miteinander verglichen, was einerseits mit der Popularität beider Systeme zusammenhängt, aber vielleicht auch mit den starken Meinungen von Linus Torvalds gegenüber Subversion (und insbesondere [[CVS]]). Dieser Abschnitt nimmt sich der wichtigsten Argumente an, und soll als Entscheidungshilfe dienen.

=== Vorteile von git ===
Das dezentrale System von git bietet viel Komfort für Programmierer. Anders als bei Subversion kann auch jeder, der nicht zum Kernentwicklerteam gehört, und keinen Schreibzugriff auf das Archiv hat, jederzeit alle Möglichkeiten, die das SCM bietet, ausnutzen. Niemand hindert den Entwickler daran, in seinem Archiv commits zu machen. So wird ein Programmierer viel eher ordentliche, atomare commits machen, auch wenn diese instabil und ungetestet sind, als bei zentralen Systemen, wo ein ungetesteter commit bedeuten würde, dass jeder Entwickler nun eine instabile Version zum arbeiten bekommt. Außerdem wird so den Entwicklern das Erstellen von Patches, die früher oder später zur Mailingliste müssen, komfortabler gemacht.

=== Nachteile von git ===
''TODO: Lass sich hier mal einer was einfallen *g*''

== Kostenloses Git-Hosting ==
Für den Hobby-Betriebssystementwickler ist es sicherlich irgendwann wichtig, dass das Projekt veröffentlicht wird, und jeder einfachen Zugriff auf den Sourcecode hat. Daher gibt es hier eine Liste von kostenlosen git-Hostern.

Falls ihr ebenfalls empfehlenswerte, kostenlose Hoster kennt, oder Kommentare zu den hier aufgelisteten habt, dann zögert nicht, diese hier hinzuzufügen

* [http://repo.or.cz repo.or.cz]: Nur grundlegende Funktionen.

* [http://github.com Github]: Kostenlos für Open-Source-Projekte. Bietet weitere Features, zum Beispiel Beobachtungslisten für die Aktivitäten anderer Entwickler und Projekte.

* [http://gitorious.org Gitorious]: Viele Features wie Wikis, mehrere Repos pro Projekt möglich

* [http://sourceforge.net SourceForge]: Bietet noch Support für andere SCMs.

== Weblinks == 

* [http://de.wikipedia.org/wiki/Git Git bei Wikipedia]

* [http://git-scm.com/ Git Homepage] (englisch)

* [http://git-scm.com/documentation Git Dokumentation, Anfängertutorial und Crashkurs für SVN-Umsteiger] (englisch)

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Rede von Linus Torvalds über git] (englisch)

* [http://git.or.cz/gitwiki/LinusTalk200705Transcript Transskription dieser Rede] (englisch)

* [http://git.wiki.kernel.org/index.php/GitFaq Eine FAQ zu Git, die fast alle geläufigen Probleme lösen kann] (englisch)

[[Kategorie:Versionsverwaltung]]