Git hat sich als Tool für die Versionsverwaltung an vielen Stellen als de-facto Standard etabliert. Doch halt – Schritt zurück! Versionsverwaltung? Fangen wir doch zunächst mit den grundlegendsten Begrifflichkeiten an. 

Was soll das mit der Versionsverwaltung?

Bei der Versionsverwaltung (oder auch Quellcodeverwaltung) geht es vordergründig zunächst darum, die eigene Arbeit, also das Projekt, an dem Ihr arbeitet, an einem zentralen Punkt zu hinterlegen. Doch eine Versionsverwaltung kann mehr, als Dateien für euch zu speichern. Ihr könnt mit Versionsverwaltung beliebige alte Stände eures Projekts oder einzelner Dateien eures Projekts wiederherstellen. Außerdem könnt ihr zu den einzelnen Ständen eurer Dateien Kommentare hinterlegen, die den Sinn der jeweiligen Änderung festhalten. Und wenn ihr eine Versionsverwaltung verwendet, die mit einem Tool zur Projektverwaltung verknüpft ist, könnt ihr beispielsweise eine Version eures Projekts mit bestimmten Userstories oder Tasks verknüpfen.

Das ist alles sehr nützlich, wenn ihr an einem Projekt arbeitet. Am sinnvollsten natürlich, wenn mehrere Entwickler zusammenarbeiten, da dann die Änderungen auch den Personen zugeordnet werden können, doch auch wenn ihr allein an einem Projekt arbeitet, kann es durchaus helfen, einen bestimmten Stand eines Projekts wiederherstellen zu können. Und nicht nur das, eine gute Versionsverwaltung gibt euch die Möglichkeit, die Änderungen an einer Datei im Vergleich zu einem bestimmten Stand zu ermitteln. Das bedeutet ihr könnt nicht nur an den Kommentaren im Commit ablesen, was sich an einer Datei geändert hat, ihr könnt sogar „zurück in der Zeit reisen“ und die Änderungen im Vergleich zu einem alten Stand erkennen.

„Moment“, sagt jetzt der erfahrene Microsoft BI Entwickler, „wir arbeiten in SSIS beispielsweise doch gar nicht im Source code und funktioniert das auch bei Datenbankprojekten?“… Natürlich ist es hier für Entwickler von Datenbankprojekten nicht so einfach wie für Programmierer, deren Code ja üblicherweise lesbar sein sollte. Das ist sicher auch einer der Gründe, weshalb sich BI- und Datenbankentwickler traditionell mit Werkzeugen wie Versionsverwaltung schwerer tun als klassische Softwareentwickler. Wir möchten euch nun in den nächsten Absätzen einige Grundprinzipien von Versionsverwaltung am Beispiel von Git erklären und euch die Hilfsmittel in die Hand geben, um diese Tools auch als BI- oder Datenbankentwickler verwenden zu können.

Was ist eigentlich dieses Git?

Git ist eine freie Software zur Versionsverwaltung, die von Linus Torvalds initiiert wurde (ja, dem Linux-Linus). Im Laufe der Zeit gab es verschiedene Ansätze, wie Versionsverwaltung funktionieren kann. Tools wie die Team Foundation Version Control (TFVC), die im Team Foundation Server (TFS) verwendet wurde oder Subversion (SVN), basieren im Wesentlichen auf einer zentralen Datenbank, mit der alle Entwickler ihre Änderungen abgleichen. Jeder Entwickler hat dabei immer genau eine Version des Projekts auf seinem lokalen Rechner, die er dann (hoffentlich) in regelmäßigen Abständen auf den zentralen Server synchronisiert.

Git „tickt“ hier ein wenig anders: hier hat jeder Entwickler eine komplette Versionsverwaltung auf seinem Rechner und synchronisiert seine Arbeit in erster Linie mit dieser lokalen Versionsverwaltung. Wenn er dann Änderungen produziert hat, die groß genug sind, um sie anderen Entwicklern bereitzustellen oder in das Projekt zu übernehmen, synchronisiert er seine lokale Versionsverwaltung mit einer zentralen Versionsverwaltung, die aber auch nichts weiter ist als eine Instanz von Git. Die Idee dahinter ist, dass die Entwickler gerne und oft auch unvollständige Arbeitsstände in ihr lokales Git synchronisieren sollen und nicht zu lange warten, bis möglicherweise größere Arbeitspakete abgeschlossen wurden.

Klären wir aber zunächst einige Grundbegriffe bei der Arbeit mit Git:

• Repository: ein Repository oder Repo ist wörtlich übersetzt ein „Depot“ oder „Aufbewahrungsort“ – und genauso ist es in Git zu verstehen, das Repository ist die Stelle, an der Euer Quellcode „aufbewahrt“ wird. Dabei wird hier der Quellcode auch „sortiert“, also versioniert. Ihr findet hier alle Änderungen an allen Dateien, die ihr hier „eingelagert“ habt. Bei Git habt ihr in der Regel mehrere Repositories, die ihr miteinander synchronisiert, ein lokales Repo auf das üblicherweise nur ihr selbst zugreift und ein Remote-Repo auf das das gesamte Team zugreift.
• Commit: Unter einem Commit versteht man das „Einlagern“ von Änderungen (egal ob Änderungen an bestehenden Dateien oder Änderungen in Form des Hinzufügens von Dateien am Repository). 
• Push/Pull: Hiermit ist der Vorgang gemeint, Änderungen aus dem zentralen Remote-Repo abzuholen und in euer lokales Repository zu übertragen beziehungsweise Änderungen in eurem lokalen Repository an das zentrale Remote-Repo zu übertragen. Wichtig ist dabei: wenn ihr lokal an Dateien gearbeitet habt, die mittlerweile im Remote Repo von jemandem anders seinerseits verändert wurden, dann erkennt eure Versionsverwaltung das und ihr müsst die Dateien „mergen“, also die Änderungen in einer Datei zusammenführen. Im Falle von Quellcode ist das zwar gelegentlich aufwändig, aber doch in der Regel machbar. Bei Dateien wie SSIS-Paketen, wo nicht der Quellcode direkt bearbeitet wird, sind die Änderungen oftmals nicht lesbar für den Entwickler und der Merge somit oftmals nicht ohne weiteres durchführbar. Noch schlimmer ist es natürlich mit Binärdateien, die man deshalb üblicherweise nicht in einer Versionsverwaltung hinterlegt. Wenn ihr das dennoch tut, müsst ihr euch eben für eine der beiden Dateien entscheiden und die Änderungen in der anderen Version aufgeben.
• Branch: Wenn ihr in einem Projekt mit Versionsverwaltung arbeitet, bietet es sich an, ein Branching-Konzept zu verfolgen. Beim Branching wird nicht nur eine lokale Kopie des Repositories verwendet, sondern diese in einen eigenen „Entwicklungsstrang“ gekapselt. So gibt es in Softwareprojekten oft „Feature Branches“, also „Abzweigungen“, in denen explizit an einem Feature gearbeitet wird. So können Änderungen in anderen Branches, die idealerweise andere Bereiche des Quellcodes betreffen, „ausgeklammert“ werden, bis ein Feature fertiggestellt wird. Typischerweise wird ein Branch geschlossen (gelöscht), wenn die Entwicklung am dazugehörigen Feature abgeschlossen ist und die Änderungen übernommen wurden.
• Master: In Git gibt es üblicherweise einen „Haupt-Branch“. Wenn ihr euch die Versionsverwaltung mit allen ihren „Abzweigungen“ als Baum vorstellt, dann ist der Master-Branch der „Stamm“ des Baumes. Üblicherweise ist das auch der Branch aus dem dann ein Release entsteht, also ein veröffentlichbarer Stand des Projekts. Das geschieht üblicherweise, wenn die Feature-Branches aller Features, die ins Release übernommen werden sollen, mit dem Master-Branch zusammengeführt wurden.

Nun habt ihr die Grundkonzepte von Git kennengelernt, beim nächsten Mal möchten wir uns damit beschäftigen, wie ihr Git praktisch verwenden könnt und welche (wenigen) Befehle ihr dafür kennen müsst.