'''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.

== 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>.

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.

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.

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 tyndur). 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.

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

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

== 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, jedereit 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]

* [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)