Ein 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 neues .git-Unterverzeichnis in deinem aktuellen Arbeitsverzeichnis erstellt. Dabei wird auch ein neuer Haupt-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.
Zugehöriges Material
git branch
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
cd /path/to/your/existing/code
git initWenn 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.orgBENUTZERNAME: rhyolightNAME DES REPOSITORYS: javascript-data-store
Wenn du die URL ausführst, wird die neueste Version der Dateien aus dem Remote-Repository im Haupt-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 Haupt-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.txtmit 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 "test content for git tutorial" >> CommitTest.txt
git add CommitTest.txt
git commit -m "added CommitTest.txt to the repo"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, kannst du lokale Branches dorthin verschieben.
git push -u <remote_name> <local_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:
/.git/config - 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 <email>Lege die E-Mail-Adresse des Autors fest. Diese verwendet der aktuelle Benutzer bei allen Commits.
git config --global alias.<alias-name> <git-command>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 commitDaraufhin 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.
it 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 --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:
/.git/config ~/.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 = vimAlle 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.comWähle deinen bevorzugten Texteditor aus.
git config --global core.editor vimFü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 commitSo wird die Datei ~ /.gitconfig aus dem letzten Abschnitt erzeugt. Genauere Infos zu git config erhältst du auf der Seite zur Git-Konfiguration.
Zusammenfassung
Wir haben hier zwei Methoden zum Erstellen eines Git-Repositorys gezeigt: git init und git clone. Dieser Leitfaden hilft dir beim Verwalten von Software-Quellcode und anderen Inhalten, die versioniert werden müssen. Außerdem wurden git add, git commit, git push und git remote eingeführt und veranschaulicht.
Lies unseren Leitfaden und finde heraus, welches Code-Repository-System für dein Team am besten geeignet ist!
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
