Git und die wichtigsten Befehle für den professionellen Einsatz

Inhalt

1. Schnelleinstieg – Die wichtigsten Git Befehle
2. Was ist Git?
3. Voraussetzungen
4. Git-Befehle ausführlich erklärt

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.

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.