Ein Repository einrichten

Repository einrichten

Dieses Tutorial bietet einen Überblick zur Einrichtung eines Repositorys (Repos) mithilfe der Git-Versionskontrolle. Wir erklären, wie du ein Git-Repository für ein neues oder ein bestehendes Projekt anlegst. Im Weiteren stellen wir Workflow-Beispiele für Repositorys vor, die entweder lokal erstellt oder von Remote-Repositorys geklont wurden. In diesem Leitfaden wird ein Grundwissen zu Befehlszeilenschnittstellen vorausgesetzt.

Dieser Leitfaden behandelt folgende allgemeine Punkte:

  • Neues Git-Repository anlegen
  • Bestehendes Git-Repository klonen
  • Bearbeitete Dateiversion an ein Repository committen
  • Git-Repository zur Remote-Zusammenarbeit konfigurieren
  • Häufige Befehle zur Git-Versionskontrolle

Am Ende dieses Moduls bist du in der Lage, ein Git-Repository zu erstellen, gängige Git-Befehle zu nutzen, eine bearbeitete Datei zu committen, deinen Projektverlauf anzeigen zu lassen und eine Verbindung zu einem Hosting-Service für Git (Bitbucket) zu konfigurieren.

Was ist ein Git-Repository?

Ein Git-Repository ist ein virtueller Speicher deines Projekts. Damit kannst du Versionen deines Codes speichern und bei Bedarf auf sie zugreifen. 

Neues Repository anlegen: git init

Zum Erstellen eines neuen Repositorys benutzt du den Befehl git init. git init ist ein einmaliger Befehl während der Ersteinrichtung eines neuen Repositorys. Durch das Ausführen dieses Befehls wird ein .git-Unterverzeichnis in deinem aktuellen Arbeitsverzeichnis erstellt. Dabei wird auch ein neuer Master-Branch erstellt. 

Versionsverwaltung bei bestehendem Projekt mit einem neuen Git-Repository

In diesem Beispiel setzen wir voraus, dass du bereits einen Projektordner hast, in dem du ein Repository erstellen willst. Zuerst führst du cd auf den Root-Ordner des Projekts aus und anschließend den Befehl git init.

cd /path/to/your/existing/code
git init

Wenn du mithilfe von git init einen Verweis zu einem bestehenden Projektverzeichnis herstellst, wird dieselbe Einrichtung zum Anlegen wie oben erläutert durchgeführt, jedoch auf dieses Projektverzeichnis beschränkt.

git init <project directory>

Sieh dir die Seite zu git init an, um mehr über git init zu erfahren.

Bestehendes Repository klonen: git clone

Wenn ein Projekt bereits in einem zentralen Repository eingerichtet wurde, ist ein Klon-Befehl für Benutzer die gängigste Art, einen lokalen Entwicklungsklon zu erstellen. Genau wie git init ist das Klonen im Allgemeinen ein einmaliger Vorgang. Sobald ein Entwickler eine Arbeitskopie erhalten hat, werden alle Versionskontrollvorgänge über sein lokales Repository verwaltet.

git clone <repo-url>

git clone wird verwendet, um eine Kopie oder einen Klon eines Remote-Repositorys zu erstellen. Du ordnest git clone eine Repository-URL zu. Git unterstützt einige verschiedene Netzwerkprotokolle und die entsprechenden URL-Formate. In diesem Beispiel verwenden wir das Git-SSH-Protokoll. Die Git-SSH-URLs sind wie folgt aufgebaut: git@HOSTNAME:USERNAME/REPONAME.git

Eine Git-SSH-URL könnte zum Beispiel so aussehen: git@bitbucket.org:rhyolight/javascript-data-store.git,, wobei folgende Vorlagenwerte gelten:

  • NAME DES HOSTS: bitbucket.org
  • BENUTZERNAME: rhyolight
  • NAME DES REPOSITORYS: javascript-data-store

Wenn du die URL ausführst, wird die neueste Version der Dateien aus dem Remote-Repository im Master-Branch per Pull weiter nach unten verschoben und einem neuen Ordner hinzugefügt. Der Name des neuen Ordners richtet sich nach dem NAMEN DES REPOSITORYS, in diesem Fall javascript-data-store. Der Ordner enthält den gesamten Verlauf des Remote-Repositorys sowie einen neu erstellten Master-Branch.

Weitere Dokumentation zum Gebrauch von git clone und unterstützten Git-URL-Formaten findest du auf der Seite zu git clone.

Änderungen am Repository speichern: git add und git commit

Wenn du jetzt ein Repository geklont bzw. angelegt hast, kann du die Änderungen an der Dateiversion dorthin committen. Im folgenden Beispiel gehen wir davon aus, dass du ein Projekt unter /path/to/project eingerichtet hast. Hier sind die Schritte, die in diesem Beispiel durchzuführen sind:

  • Verzeichnis zu /path/to/project ändern
  • Erstelle eine neue Datei, CommitTest.txt, mit den Inhalten ~"testinhalt für git-tutorial"~
  • Füge CommitTest.txt mit git add der Staging-Umgebung des Repositorys hinzu.
  • Erstelle einen neuen Commit mit einer Nachricht, in der du beschreibst, welche Aufgaben mit dem Commit erledigt worden sind.
cd /path/to/project
echo "testinhalt für git-tutorial" >> CommitTest.txt
git add CommitTest.txt
git commit -m "CommitTest.txt zu repository hinzugefügt"

Nachdem du diesen Test durchgeführt hast, hat das Repository nun CommitTest.txt dem Verlauf hinzugefügt und künftige Aktualisierungen an der Datei werden nachverfolgt.

In diesem Beispiel werden zwei neuen Git-Befehle eingeführt: add und commit. Dieses Beispiel war stark verkürzt. Die beiden Befehle werden auf den Seiten zu git add und git commit ausführlicher behandelt. Ein weiterer häufiger Verwendungszweck für git add ist die Option --all. Mit dem Befehl git add --all werden alle geänderten und nicht verfolgten Datei in das Repository aufgenommen und ihm hinzugefügt und die Arbeitsbaumstruktur des Repositorys aktualisiert.

Zusammenarbeit von Repository zu Repository: git push

Es ist wichtig zu verstehen, dass "Arbeitskopien" in Git völlig anders funktionieren als Arbeitskopien, die du beim Checkout von Quellcode aus einem SVN-Repository erhältst. Im Gegensatz zu SVN unterscheidet Git nicht zwischen Arbeitskopien und dem zentralen Repository – alle sind vollwertige Git-Repositorys.

Damit ist die Zusammenarbeit mit Git grundsätzlich anders als mit SVN. Während es bei SVN auf das Verhältnis zwischen zentralem Repository und Arbeitskopie ankommt, basiert die Zusammenarbeit mit Git auf der Interaktion zwischen Repositorys. Statt eine Arbeitskopie in ein zentrales Repository auszuchecken, verschiebst du Commits oder führst Pulls für Commits von einem in das andere Repository durch.

Natürlich kannst du bestimmten Git-Repositorys auch eine besondere Rolle zuzuweisen. Wenn du etwa ein Git-Repository als "zentrales" Repository definierst, kannst du einen zentralen Workflow mithilfe von Git replizieren. Das wird vielmehr durch Festlegungen und nicht durch Vorgaben des VCS selbst erreicht.

Bare- vs. geklonte Repositorys

Wenn du im letzten Abschnitt, "Ein neues Repository anlegen", den Befehl git clone verwendest hast, ist dein Repository bereits zur Remote-Zusammenarbeit konfiguriert. Mit git clone konfigurierst du dein Repository automatisch mit einem Remote-Repository, auf das du mit der Git-URL verweist, von der du es geklont hast. Das bedeutet, dass du, sobald du eine Datei geändert und die Änderungen committet hast, diese Änderungen mit dem Befehl git push in das Remote-Repository verschieben kannst.

Wenn du ein neues Repository mithilfe von git init angelegt hast, hast du kein Remote-Repository, in das du deine Änderungen verschieben könntest. Üblicherweise hostet man beim Anlegen eines neuen Repositorys einen Git-Service wie Bitbucket und erstellt dort ein Repository. Der Service stellt eine Git-URL bereit, die du deinem lokalen Git-Repository hinzufügst und über den Befehl git push in das gehostete Repository verschiebst. Sobald du mithilfe eines von dir gewählten Services ein Remote-Repository erstellt hast, musst du dein lokales Repository mit einem Mapping aktualisieren. Auf diesen Prozess gehen wir im Leitfaden zur Konfiguration und Einrichtung weiter unten genauer ein.

Wenn du lieber dein eigenes Remote-Repository hosten willst, musst du ein "Bare-Repository" einrichten. Sowohl git init als auch git clone erlauben das Argument --bare. Am häufigsten verwendet man Bare-Repositorys, um ein zentrales Remote-Git-Repository zu erstellen.

Konfiguration und Set-up: git config

Sobald du ein Remote-Repository eingerichtet hast, musst du deinem lokalen Befehl git config eine URL für das Remote-Repository hinzufügen und einen Upstream-Branch für deine lokalen Branches einrichten. Dazu dient der Befehl git remote.

git remote add <remote_name> <remote_repo_url>

Mit diesem Befehl wird das Mapping des Remote-Repositorys unter <remote_repo_url> zu einer Referenz in deinem lokalen Repository unter <remote_name> durchgeführt. Sobald du das Mapping für das Remote-Repository abgeschlossen hast, kann du lokale Branches dorthin verschieben.

git push -u <remote_name> <lokaler_branch_name>

Mit diesem Befehl verschiebst du den lokalen Repository-Branch unter <local_branch_name> in das Remote-Repository unter <remote_name>.

Genauere Infos zu git remote erhältst du auf der Seite zu git remote.

Neben der Konfiguration einer URL für das Remote-Repository musst du eventuell auch globale Git-Konfigurationsoptionen wie etwa Benutzername und E-Mail-Adresse einrichten. Mit dem Befehl git config kannst du deine Git-Installation (oder ein einzelnes Repository) über die Befehlszeile konfigurieren. Mit diesem Befehl kannst du alles definieren: von Benutzerangaben über bevorzugte Einstellungen bis zum Verhalten eines Repositorys. Einige gängige Konfigurationsoptionen stellen wir im Folgenden vor.

Git speichert Konfigurationsoptionen in drei separaten Dateien. Dadurch kannst du die Optionen auf einzelne Repositorys (lokal), Benutzer (global) oder das ganze System (System) anwenden:

  • Lokal: <repo>/.git/config – Repository-spezifische Einstellungen
  • Global: /.gitconfig – Benutzerspezifische Einstellungen. Dort werden die mit --global gekennzeichneten Optionen gespeichert.
  • System: $(prefix)/etc/gitconfig – Systemweite Einstellungen

Lege den Namen des Autors fest, der für sämtliche Commits im aktuellen Repository verwendet werden soll. Bei der Definition der Konfigurationsoptionen des aktuellen Benutzers empfiehlt es sich in der Regel, das Flag --global zu setzen.

git config --global user.name <name>

Lege den Namen des Autors fest. Diesen verwendet der aktuelle Benutzer bei allen Commits.

Wenn du die Option --local hinzufügst oder die Konfigurationsebene überspringst, wird der user.name für das aktuelle lokale Repository festgelegt.

git config --local user.email <e-mail>

Lege die E-Mail-Adresse des Autors fest. Diese verwendet der aktuelle Benutzer bei allen Commits.

git config --global alias.<alternativer-benutzername> <git-befehl>

Erstelle ein Kürzel für einen Git-Befehl. Das ist sehr nützlich, um spezifische Kürzel für häufig verwendete Git-Befehle zu erstellen. Grob vereinfacht würde das so aussehen:

git config --global alias.ci commit

Daraufhin wird der Befehl ci generiert, den du als Kürzel für git commit verwenden kannst. Wenn du mehr über Git-Aliasse erfahren willst, sieh dir die Seite zu git config an.

git config --system core.editor <editor>

Lege den Texteditor fest, der für Befehle wie git commit bei allen Benutzern im aktuellen System genutzt werden soll. Das Argument <editor> sollte der Befehl sein, der den gewünschten Editor startet (z. B. vi). In diesem Beispiel wird die Option --system eingeführt. Die Option --system legt die Konfiguration für das gesamte System fest, also für alle Benutzer und Repositorys einer Maschine. Ausführliche Informationen zu Konfigurationsebenen findest du auf der Seite zu git config.

git config --global --edit

Öffnet die globale Konfigurationsdatei in einem Texteditor zur manuellen Bearbeitung. Ein detaillierter Leitfaden zur Konfiguration eines Texteditors für Git findest du auf der Seite zur Git-Konfiguration.

Diskussion

Alle Konfigurationsoptionen werden in reinen Textdateien gespeichert. Der Befehl git config ist wirklich nur eine praktische Befehlszeilenschnittstelle. Üblicherweise musst du eine Git-Installation nur dann konfigurieren, wenn du zum ersten Mal mit einer neuen Entwicklungsmaschine arbeitest, sowie nahezu jedes Mal, wenn du die Kennzeichnung --global verwendest. Eine wichtige Ausnahme gibt es beim Überscheiben der E-Mail-Adresse des Autors. Du willst vielleicht deine private E-Mail-Adresse für private und Open-Source-Repositorys einstellen, aber deine Arbeits-E-Mail-Adresse für arbeitsbezogene Repositorys.

Git speichert Konfigurationsoptionen in drei separaten Dateien. Dadurch kannst du die Optionen auf einzelne Repositorys, Benutzer oder das ganze System anwenden:

  • <repo>/.git/config – Repository-spezifische Einstellungen
  • ~/.gitconfig – Benutzerspezifische Einstellungen. Dort werden die mit --global gekennzeichneten Optionen gespeichert.
  • $(prefix)/etc/gitconfig – Systemweite Einstellungen

Kommt es zwischen den Optionen in diesen Dateien zu Konflikten, werden Benutzereinstellungen von lokalen Einstellungen und schließlich systemweit überschrieben. Wenn du eine dieser Dateien öffnest, siehst du etwa Folgendes:

[user] name = John Smith email = john@example.com [alias] st = status co = checkout br = branch up = rebase ci = commit [core] editor = vim

Alle diese Werte lassen sich auch manuell exakt so festlegen wie mit git config.

Beispiel

Nach der Installation von Git wirst du zunächst deinen Namen/E-Mail-Adresse angeben und die Standardeinstellungen personalisieren. Eine typische Erstkonfiguration kann etwa wie folgt aussehen:

Teile Git über git config mit, wer du bist.

git --global user.name "John Smith" git config --global user.email john@example.com

Wähle deinen bevorzugten Texteditor aus.

git config --global core.editor vim

Füge SVN-ähnliche Aliasse hinzu.

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.up rebase
git config --global alias.ci commit

So wird die Datei ~ /.gitconfig aus dem letzten Abschnitt erzeugt. Genauere Infos zu git config erhältst du auf der Seite zur Git-Konfiguration.

Summary

Wir haben hier zwei Möglichkeiten gezeigt, wie du ein Git-Repository erstellen kannst: git init und git clone. Dieser Leitfaden hilft dir beim Managen von Software-Quellcode und anderen Inhalten, die versioniert werden müssen. Außerdem wurde Allgemeines zu git add, git commit, git push und git remote eingeführt und veranschaulicht. 

Lies unseren Guide und finde heraus, welches Code-Repository-System für dein Team am besten geeignet ist

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen