Vielen wird es wohl ähnlich ergangen sein. Wenn man als Neuling anfängt ein paar Websites zu bearbeiten, wird man relativ schnell mit FTP Bekanntschaft machen. Das File Transfer Protokoll ermöglicht es, einfach Dateien vom eigenen Rechner auf einen Server hochzuladen. FTP ist einfach zu bedienen, und funktioniert auch, solange man alleine an einem Projekt arbeitet. Wenn aber dieser Neuling nun in eine Gruppe kommt, wo mehrere Leute gleichzeitig an einem Code arbeiten, ist meist Schluss mit FTP. Dann muss man sich mit so kompliziertem Zeug wie GIT anfreunden.

Viele Neulinge stänkern dann erst mal. „Aber mit FTP hat es doch bei mir auch wunderbar funktioniert. Weshalb nun plötzlich so ein kompliziertes Tool?“ GIT ist tatsächlich ein komplizierteres Tool als FTP und der Unterschied ist erst mal nicht so offensichtlich. Den will ich Euch heute erklären.

Die Grenzen von FTP

Wenn man vom eigenen Rechner via FTP auf einen Webserver eine Datei oder mehrere hochlädt, wird die alte Datei einfach überschrieben. Klingt erst mal logisch, ist ja auf dem lokalen Rechner genau so. Doch wenn mehrere Leute an einer Website arbeiten kann das zu einem heillosen durcheinander führen. Ein Beispiel: Entwickler eins macht in einer Datei eine Änderung… informiert aber nicht gleich das Team. Er lädt die Datei auf den Server hoch. Dann kommt Entwickler zwei und will auch ein paar Änderungen machen. Nur hat er noch eine Datei ohne die Änderungen von Entwickler eins. Wenn nun Entwickler zwei seine Änderungen auf den Server hochlädt, sind die Änderungen von Entwickler eins einfach überschrieben. Dieses Problem schlägt schon bei ganz kleinen Teams zu, weshalb eigentlich alle Entwicklungsteams auf eine Versionskontrolle (GIT ist eine von vielen) setzen.

GIT speichert Change sets, keine komplette Dateien

Der eigentliche Unterschied zwischen einem FTP Server und GIT liegt im Hintergrund verborgen. Im Unterschied zu einem FTP Server speichert GIT nämlich die Änderungen in sog. Change sets. Das sieht dann ungefähr so aus:

Initial commit	Version 1
Changeset 1	Version 2
Changeset 2	Version 3
Changeset 3	Version 4

Wenn man also etas via GIT auf ein Repository (wie man die Ablage nennt) hochlädt, dann erstellt GIT erst auf dem eigenen Rechner ein Change set. Dieses wird dann an den Server übermittelt. Die Change Sets funktionieren Zeilenbasiert. An folgendem Screenshot kann man das sehr gut erkennen:

Die Dateien die man also in Git erhält, sind immer aus vielen einzelnen Change sets zusammengezimmert worden.

Dieses System eröffnet ganz andere Möglichkeiten. Zum einen können so Fehler einfach zurückgespult werden. Zum anderen ist es möglich, Änderungen eines anderen Entwicklers in den eigenen Quellcode einzubauen auch wenn man selbst schon Änderungen gemacht hat.

GIT ist zwar komplizierter zu bedienen, vereinfacht aber letztendlich vieles. Selbst das kleine Einmann Projekt profitiert davon. Insbesondere wenn man was einbauen wollte, und erst zu spät bemerkt, dass es nicht funktioniert. Mit GIT kann man die Änderung einfach zurückrollen und hat somit eine laufende Website.