In einer Reihe von Tutorials bieten wir einen Überblick über die gebräuchlichsten Git-Befehle. Zunächst soll Git aufgesetzt werden, um mit einem neuen Projekt mit Versionskontrolle starten zu können. Wie das funktioniert, zeigt diese Artikelserie. Los geht's mit dem Kommando git init.

git init

Das Kommando git init erzeugt ein neues Git-Repository. Es kann genutzt werden, um ein bestehendes, nicht versioniertes Projekt in ein Git-Repository zu konvertieren oder um ein neues leeres Repository zu initialisieren. Die meisten anderen Git-Befehle sind außerhalb eines initialisierten Repositorys nicht verfügbar; git init ist normalerweise das erste Kommando, das in einem neuen Projekt ausgeführt wird.

git init erzeugt ein .git-Unterverzeichnis im Projekt-Stammverzeichnis, das alle erforderlichen Metadaten für das Repo enthält. Abgesehen vom .git-Verzeichnis bleibt das bestehende Projekt unverändert. (Anders als SVN benötigt Git keinen .git-Ordner in jedem Unterverzeichnis.)

Anwendung

git init

Transformiert das aktuelle Verzeichnis in ein Git-Repository. Im aktuellen Verzeichnis wird ein .git-Ordner angelegt. Es ist nun möglich, Revisionen des Projekts aufzuzeichnen.

git init <verzeichnis>

Erzeugt ein leeres Git-Repository in diesem spezifischen Verzeichnis. Dieser Befehl legt einen neuen Ordner namens <verzeichnis> an, der nichts als das .git-Unterverzeichnis enthält.

git init --bare <verzeichnis>

Initialisiert ein leeres Git-Repository, lässt aber das Arbeitsverzeichnis weg. Geteilte Repositories sollten immer mit dem Zusatz --bare angelegt werden (siehe die Hinweise unten). Normalerweise enden so initialisierte Repositories auf .git. Eine leere Version einer Repository namens mein-projekt sollte also in einem Verzeichnis namens mein-projekt.git gespeichert werden.

Hinweise

Im Vergleich zu SVN ist das Kommando git init ein wirklich einfacher Weg, um neue versionskontrollierte Projekte aufzusetzen. Git verlangt nicht, ein Repository zu erstellen, Dateien zu importieren und eine Arbeitskopie auszuchecken. Der Entwickler muss mit cd nur in seinen Projektordner gehen und git init ausführen, um ein voll funktionsfähiges Git-Repository zu erzeugen.

In den meisten Projekten muss git init allerdings nur ein Mal ausgeführt werden, nämlich um ein zentrales Repo anzulegen. Entwickler nutzen git init normalerweise nicht, um ihre lokalen Repositories zu erzeugen. Stattdessen wenden sie git clone an, um ein bestehendes Repository auf ihre lokalen Rechner zu kopieren.

Leere Repositories

Mit der Option --bare wird ein Repo angelegt, das kein Arbeitsverzeichnis hat. Es ist also nicht möglich, in diesem Repository Dateien zu editieren und Änderungen zu committen. Zentrale Repositories sollten immer als leere Repos angelegt werden, da in ein nicht leeres Repo gepushte Branches das Potenzial haben, Änderungen zu überschreiben. --bare ist sozusagen ein Weg, um ein Repository als einen Speicherort zu markieren, im Gegensatz zu einer Entwicklungsumgebung. Das bedeutet, dass für praktisch alle Git-Workflows das zentrale Repo leer ist, während die lokalen Repos der Entwickler es nicht sind.

Beispiel

Da git clone ein sehr praktischer Weg ist, um lokale Kopien eines Projekts anzulegen, besteht der häufigste Anwendungsfall für git init darin, ein zentrales Repository aufzusetzen:

ssh <user>@<host>
cd path/above/repo
git init --bare mein-projekt.git

Zunächst meldet sich der Entwickler mit SSH am Server an, der das zentrale Repository enthalten soll. Dann navigiert er an den Ort, an dem er das Projekt speichern will. Zum Schluss nutzt er den Zusatz --bare, um ein zentrales Repo zum Speichern anzulegen. Andere Entwickler würden dann mit git clone von dort aus lokale Kopien auf ihre Entwicklungsrechner ziehen.

Dazu mehr im zweiten Teil des Tutorials.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

99 Argumente für Stash als Git-Repository-Manager
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten