Inhalt
- Schnelleinstieg – Die wichtigsten Git Befehle
- Was ist Git?
- Voraussetzungen
- Git-Befehle ausführlich erklärt
- Glossar
1. Schnelleinstieg – Die wichtigsten Git Befehle
$ git init
Ein lokales Verzeichnis als Git Repository initialisieren.
$ git remote add origin https://gitlab.com/dr/projekt.git
Das lokale Projekt mit dem entfernten Git Repository verknüpfen.
$ git status
Den aktuellen Stand zu Änderungen, Branches, Commits anzeigen.
$ git add .
Das aktuelle Projekt dem Staging-Bereich hinzufügen.
$ git reset HEAD datei.js
Datei aus dem Staging-Bereich zurücknehmen.
$ git commit -m "initial commit"
Den aktuellen Stand aus dem Staging- in den Index-Bereich aufnehmen.
$ git push
Die Änderungen aus dem Index-Bereich auf das entfernte Git-Repository hochladen.
$ git pull
Den aktuellen Stand des Git-Repositories auf das lokale Repository ziehen/aktualisieren.
$ git branch
Damit erstellst du einen neuen Zweig, in dem z.B. ein Feature entwickelt werden kann.
$ git checkout -b feature-01 master
Erzeugt einen Feature-Branch aus dem des Master-Branch.
$ git diff feature-01 master
Zeigt Unterschiede vom Quell- zum Zielbranch an.
$ git merge feature-01
Fügt Änderungen aus dem Feature-Branch mit einem anderen, z.B. dem Master zusammen.
Und nun der Reihe nach:
2. Was ist Git?
Git ist ein weltweit verbreitetes Tool zur Versionsverwaltung von Software-Versionen und zur Kollaboration. Git wurde von Linus Torvalds bereits 2005 entwickelt und gilt mittlerweile als Industriestandard.
Software-Projekte werden als Repositories dezentral verwaltet, dass heißt, jeder Entwickler hat sein eigenes lokales Repository, in dem die Versionen gespeichert werden. Die Versionen werden dann in einem gemeinsamen Repository zentral zusammengefügt.
Das zentrale Repository kann lokal oder bei einem Git-Hosting-Provider angelegt werden. Bekannte Provider für das Hosting von Software-Projekten sind GitHub, GitLab und Bitbucket.
Gitlab wird als DevOps-Plattform bezeichnet, mit der Entwickler ihre Software-Projekte hosten, verwalten und durch Continuous Integration das Deployment automatisieren können.
Hosting-Provider bieten viele weitere Möglichkeiten z.B. Funktionalitäten zur Kollaboration oder zur Continuous Integration. Darauf gehe ich in diesem Blog-Artikel nicht detaillierter ein.
3. Voraussetzungen
Git lokal installieren
Git muss lokal installiert werden, damit du es nutzen kannst. Die Download-Links für Windows und Mac, bzw. die Installation per Package Manager unter Linux findest du hier:
Windows: https://git-scm.com/download/win
Mac: https://git-scm.com/download/mac
Linux: https://git-scm.com/download/linux
Account bei einem Git-Hosting-Provider anlegen
Bei den bereits genannten führenden Git-Hostern musst du einen Account angelegen, über den das entfernte Repository erstellt werden kann. Hier die Links der von mir empfohlenen Anbieter, wobei es auch diverse weitere Anbieter gibt:
GitHub: https://github.com/
GitLab: https://gitlab.com/users/sign_in
Bitbucket: https://bitbucket.org/account/signup/
Graphical User Interface (GUI) verwenden
Willst du Git nicht über das Command Line Interface (CLI) verwenden, kannst du auch eine GUI installieren, das je nach Tool die einzelnen User, Commits, Branches und/oder Logs grafisch darstellt. Eine Auswahl einiger Tools findest du hier:
Sourcetree (Windows, Mac)
GitHub Desktop (Windows, Mac)
MercurialGit (Windows)
Und viele weitere, die du hier findest https://git-scm.com/downloads/guis/
4. Git-Befehle ausführlich erklärt
4.1 git init
Damit ein lokales Verzeichnis erstmals als Git Repository initialisiert wird, verwendest du
$ git init
Ab diesem Zeitpunkt werden alle Dateien in diesem Verzeichnis versioniert. Mit
$ git status
kannst du testen, ob die Initialisierung erfolgreich war, die Konsolenausgabe zeigt dir auf welchem Branch du dich befindet („On branch master“). Außerdem wurde damit ein Verzeichnis Namens .git angelegt, in dem deine Versionen gespeichert werden.
4.2 git remote
Der remote-Befehl wird zur Verwendung externer Repositories genutzt. Ohne weitere Optionen kannst du mit
$ git remote
die aktuell verwendeten Remote-Repositories anzeigen. Mit der Option -v werden dir die jeweiligen URL´s angezeigt.
Mit dem bereits genannten Befehl
$ git remote add origin https://gitlab.com/dr/projekt.git
fügst du ein neues entferntes Repository hinzu.
Mit dem Befehl
$ git remote show origin
werden erweiterte Informationen zum Repository origin angezeigt, z.B. die verschiedenen Branches, die für git push bzw. git pull konfiguriert sind.
4.3 git status
Den aktuellen Status rufst du mit
$ git status
auf. Weitere Optionen sind z.B. -s (short) für die Kurzausgabe der Anzeige oder -u für die untracked Files.
4.4 git add
Der bereits gezeigte Befehl git add . fügt Änderungen der versionierten Dateien dem Staging-Bereich zu. Möchtest du nur bestimmte Unterverzeichnissse oder Dateien hinzufügen, hängst du statt dem Punkt die Dateien/Verzeichnisse an:
$ git add index.html js/script.js js/header
Zwischen den einzelnen Dateien/Verzeichnissen muss ein Leerzeichen gesetzt werden.
Willst du zukünftig Änderungen immer automatisch dem Staging-Bereich hinzufügen, kannst du das mit
$ git add --all
erreichen. Mit dem Parameter –all werden alle Dateien (geändert, hinzugefügt, gelöscht) hinzugefügt.
4.5 git reset
Hast du eine oder mehrere Dateien/Verzeichnisse durch git add dem Staging-Bereich hinzugefügt, möchtest aber mindestens ein/e Datei/Verzeichnis wieder zurücknehmen, um z.B. diese erst in einem zweiten Commit hinzuzufügen, kannst du mit
$ git reset HEAD index.html
in diesem Fall die index.html wieder als unstaged File aus dem Staging-Bereich entfernen.
Mit dem Befehl
$ git reset --soft
nimmst du Änderungen aus dem Index wieder zurück in den Staging und mit
$ git reset --hard
nimmst du Änderungen aus dem Index wieder in deinen Arbeitsbereich auf.
4.6 git commit
Hast du alle Dateien/Verzeichnisse für den ersten Commit vorbereitet, werden alle Änderungen mit
$ git commit -m "first commit"
aus dem Staging-Bereich in den Index hinzugefügt. Die Option -m wird benötigt, wenn du eine Commit-Message zum Commit erzeugen willst. Ich empfehle jeden Commit mit einer Message zu erstellen, da diese in allen Histories der IDE (Integrated Development Environment), der Git-GUI, sowie der Git-Hoster angezeigt wird.
Eine Commit-Message muss in Anführungsstrichen angegeben werden. In der Zusammenarbeit mit anderen Team-Mitgliedern, bzw. im beruflichen Kontext mit Arbeitskollegen, sind klare Konventionen zu empfehlen, wie eine Message in bestimmten Projekten und/oder Aufgabenbereichen formuliert wird.
$ git revert 86f654h
Mit dem Revert-Befehl wird der Stand des Commits mit der angegebenen Commit-ID wiederhergestellt.
4.7 git push
Für die lokale Versionsverwaltung würde das Committen ausreichen. Möchtest du aber die einzelnen Versionen auf dem entfernten Repository deinen Kollegen bei einem Git-Hoster hochladen, nutzt du
$ git push
Würdest du einen kürzlich erzeugten Branch mit git push Pushen wollen, erscheint die Fehlermeldung (feature-01 steht für einen beliebigen Branch-Namen):
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream feature-01
Wie auch schon in der Fehlermeldung vorgeschlagen, muss folgender Befehl bei erstmaligem Pushen dieses Branches verwendet werden,
$ git push --set-upstream feature-01
um einen Upstream zu erzeugen.
Gibt es beim Pushen Konflikte, liegt dass daran, dass der Commit kein Nachfahre des vorherigen Commits ist. Man kann in diesem Fall mit
$ git push --force
das Pushen erzwingen, erzeugt damit aber eine History mit abgeschnittenem Branch. Dass heißt, dass ein Branch oder Branches anderer Entwickler entfernt werden und damit auch nicht mehr in der History auftauchen.
4.8 git pull
Wenn mehrere Kollegen/Team-Mitglieder in dem Repository arbeiten, entstehen unterschiedliche Versionsstände, die du dir in regelmäßigen Abständen in dein Arbeitsbereich ziehen solltest. Mit
$ git pull
werden aktuelle Änderungen aus dem Remote-Repository in deinen Arbeitsbereich hinzugefügt.
Dabei verwendest du mit git pull eigentlich zwei Befehle. Als erstes wird git fetch zum Herunterladen der Änderungen vom Remote-Repository, dann git merge zum Zusammenfügen mit dem lokalen Stand verwendet.
4.9 git branch
Wenn du ein Feature, ein Modul, eine Komponente weiterentwickeln willst, ist der empfohlene Weg dies über ein Feature-Branch zu lösen. Der Branch wird aus dem Master heraus erstellt, man befindet sich also auf Grundlage des Codes vom Master-Branch, wenn der Feature-Branch generiert wird.
$ git branch feature-01
Ist er Branch fertiggestellt, wird er mit anderen Branches, meistens dem direkt darüberliegenden, z.B. in einfachen Git-Workflows, dem Master-Branch, zusammengefügt. Das erledigst du mit git merge, darauf gehe ich noch genauer ein.
Hat man während der Entwicklungsarbeit auf Grundlage eines sauberen Branches gearbeitet, den man nicht verändern möchte, will also im Nachhinein seine Änderungen in einen neuen noch nicht angelegten Branch übernhemen, kombiniert man git checkout mit git branch.
$ git checkout -b feature-02
Mit checkout wird nach dem Anlegen direkt in diesen Branch gewechselt.
Mit dem Befehl
$ git branch -d feature-1
wird der Branch feature-01 gelöscht.
Mit folgendem Befehl lässt sich ein bereits angelegter Branch einfach umbenennen.
$ git branch -m old-branch new-branch
Nach dem -m -Parameter wird als erstes der bisherige, mit Leerzeichen getrennt der neue Branchname angegeben.
4.10 git checkout
Git checkout aktualisiert einen anderen Stand, z.B einen anderen Branch. So gelangst du mit
$ git checkout master
wieder in deinen Master-Branch.
Möchtest du einen neuen Branch erzeugen und gleichzeitig in diesen wechseln, ist
$ git checkout -b feature-02
der entsprechende Befehl, z.B. für einen Branch Namens feature-02.
4.11 git diff
Zeigt git status die Dateien an, an denen du Änderungen vorgenommen hast, zeigt
$ git diff
die genauen Änderungen in den Dateien mit vorheriger Version (rot) im Vergleich zur aktuellen Version (grün).
Möchtest du Änderungen zweier Branches vergleichen, nutzt du
$ git diff feature-01 master
um den Feature Branch mit dem Master Branch anzuzeigen.
Die Option –cached zeigt Änderungen die im Staging-Bereich vorgemerkt sind, der gesamte Befehl ist
$ git diff --cached
Die Option –staged ist gleichbedeutend.
$ git diff 86f654h^!
Zeigt die Unterschiede zu seinem direkten Vorgänger-Commit.
4.12 git merge
Diesen schon kurz erwähnten Befehl kannst du zum Zusammenfügen von Branches verwenden. Hast du z.B. einen Branch feature-01 erstellt, in diesem gearbeitet und die Änderungen gepusht, kannst du mit folgendem Befehl Master und feature-01 zusammenfügen
$ git checkout master
$ git merge feature-01
Mit checkout wird nach erfolgtem Push in den Master-Branch gewechselt. Vom Master kann dann der mit der Angabe des zu mergenden Branches der Merge erfolgen.
Gibt es Konflikte während bzw. nach dem Mergen, kann der Befehl
$ git merge --abort
den Arbeitsbereich wieder zurücksetzen.
5. Glossar
| Branch | lokaler Zweig innerhalb des Repositories |
| Fast-Forward-Merge | Merge, der im Fall des gleichen Vorfahr den Zeiger weiter setzt |
| Head-Commit | der aktuelle Commit |
| Merge-Commit | neuer Commit, der aus einem Merge mehrerer Branches entstanden ist |
| Origin | Name für das Repository von dem geklont wurde |
| Push | Commits in ein entferntes Repository hochladen |
| Reflog | geloggte Änderungen an Branch-Zeigern |
| Remote-Branch | Zweig eines entfernten Repositories |
| Remote-Tracking-Branch | lokale Referenz auf den letzten Stand des Remote-Branches |
| Upstream-Branch | Verknüpfung von lokalem und dessem Remote-Tracking-Branch (z.B. origin/master) |
