Git: Wie Du Git mit GitHub nutzt (Howto)

In diesem Howto sind die wichtigsten Befehle für git zusammengestellt und beschrieben.

Die Ergebnisse aller beispielhaft durchgeführten Befehle sind in mein Repository git_test bei GitHub 🙂 zu finden.


Wissenswertes zu Git

Commit-Id

Alles was in Git gespeichert wird, bekommt eine eindeutige Id. Diese Id wird aus der Quersumme (Hashfunktion) über den Inhalt gebildet. Dabei wird der Algorithmus SHA-1 (Secure Hash Algorithm Variante 1) verwendet. Der Algorithmus SHA-1 erzeugt Hashes mit der Länge von 40 Zeichen (160 Bit) – aber häufig werden nur die ersten 7 Zeichen des Hashes als Kurzform verwendet (z. B. ae20eaf). Damit kann jederzeit überprüft werden, ob der Inhalt korrekt ist – indem der Hash-Wert wieder berechnet wird.

Directories und Repositories

Git besitzt ein Working Directory (Arbeitsverzeichnis), eine Staging Area (Index), ein Local Repository (Lokaler Datenspeicher) und das Remote Repository (Öffentlicher Datenspeicher). Im Arbeitsverzeichnis werden die Dateien verändert, wie bei jedem anderen Versionsverwaltungswerkzeug auch. Die vorgenommenen Änderungen werden dann in der Staging Area zum Commit zusammengestellt. Damit kann der Commit so zusammengestellt werden, wie der Entwickler es wünscht. Das Commit transferiert die Änderungen endgültig in das lokale Repository. Über den Push werden das öffentliche und lokale Repository miteinander synchronisiert.

Clon

Typischerweise wird in einem Git Repository ein Projekt abgelegt. Mehrere Repositories liegen wiederum auf einem Server. Damit unterscheidet sich Git zu anderen Versionsverwaltungswerkzeugen, die typischerweise in einem Repository mehrere Projekte verwalten. Git ist dezentral organisiert, um ein Projekt bearbeiten zu können, muss eine Kopie des Repositories geholt werden. Diese lokale Kopie nennt sich Klon. Änderungen an Dateien, neue Versionen und Branches werden zunächst in diesem Klon verwaltet. Später können diese lokalen Änderungen mit den Änderungen im Remote Repository abgeglichen werden. Neue Versionen und Branches müssen dabei separat übertragen werden.

Branch

Der Branch features-x ist in Git nur ein Zeiger auf einen Commit. Die Datei .git/refs/heads/features-x enthält die Id des Commits. Werden Änderungen in einen Branch eingebracht, so wird die Id in dieser Datei auf einen neuen Wert gesetzt. Die Branches werden normalerweise nicht automatisch mit einem entfernten Repository synchronisiert – die Änderungen (Commits) die auf einem Branch erfolgt sind – aber schon. Bestimmte Branches, wie der master, sind als Upstream markiert, diese werden mit einem entfernten Repository automatisch synchronisiert. Die Historie eines Branches entsteht aus der Historie der Vorgänger des Commits, welcher durch den Branch markiert ist. Ein Tag ist, wie die Branches, auch nur ein Zeiger auf einen Commit (Datei .git/refs/tags/v1.0).

git config

Mit diesem Befehl kann Git konfiguriert werden. In den folgenden Beispielen sind einige Konfigurationsmöglichkeiten aufgelistet. Einige Einstellungen sollten Projekt-übergreifend und abhängig vom Betriebssystem ( core.editor und merge.tool) definiert werden. Um die Lesbarkeit zu erhöhen, werden die Ausgaben eingefärbt ( color.*). Für Computer mit mehreren Prozessorkernen sollte die Option pack.threads auf 0 gesetzt werden.

Meine globalen Git Konfigurationen …

Meine Repository-spezifische Git Konfigurationen …

Beispielhafter Zugriff auf die Git Konfiguration.

git init

Im folgendem Beispielen wird ein lokales Repository erzeugt und erste einfache Befehle ausgeführt.

Alle Befehle wurden unter Linux (Kubuntu) in der Kommandozeile (Bash) ausgeführt.

Das Erstellen eines lokalen Repositories in Verzeichnis git_test.

Das Verzeichnis ~/git_test ist das Working Directory von git.

git add / git status

Das Anlegen der Dateien README.md und .gitignore für Java-Projekte.

Die neuen Dateien in den Staging Bereich hinzufügen.

Die Dateien sind nun in der lokalen Staging Area gekennzeichnet.

git commit

Die oben geänderten Dateien ins Repository überführen.

Die Dateien sind nun im Local Repository gespeichert.

git diff / git log

Die Datei README.md ändern, die Unterschiede darstellen und ins Repository stellen.

Diesmal werden die Änderungen, ohne den Befehl git add, ins lokale Repository übernommen. Statt dessen wurde die abkürzende Option git commit -a für git add --all und git commit verwendet.

Das Einrichten eines Repository bei GitHub

In den folgenden Beispielen wird ein lokales Repository mit einem öffentlichem Repository bei GitHub verbunden und die lokalen Änderungen hochgeladen.

Dazu muss bei GitHub ein Konto eingerichtet und ein öffentliches Repository angelegt werden.

Siehe dazu die folgenden Anleitungen bei GitHub:

  1. Ein freies Konto bei GitHub einrichten
  2. Einen SSH Key für GitHub erzeugen
  3. Ein öffentliches Repository bei GitHub erzeugen
    Der Name des Repositories ist git_test, eine Beschreibung angeben und die Initialisierung nicht auswählen.
    Ein neues Repository auf GitHub erzeugen

    Ein neues Repository auf GitHub erzeugen (© Frank Rahn)

git remote / git push

In diesem Beispiel wird ssh als Authentifizierungsmechanismus und Kommunikationsprotokoll verwendet.

Das lokale Repository wird mit einem entfernten Repository verbunden und die Änderungen hochgeladen.

Diesmal wird https als Authentifizierungsmechanismus und Kommunikationsprotokoll verwendet.

Das lokale Repository mit einem entfernten Repository verbinden und die Änderungen hochladen.

Das Ergebnis kann auf GitHub mit dem Browser begutachtet werden.

Das aktualisierte Repository bei GitHub

Das aktualisierte Repository bei GitHub (© Frank Rahn)

git clone

Das Holen eines öffentlichen Repositories und das Erstellen einer lokalen Arbeitskopie.

git tag / git show

Die letzten Änderungen zu einer Version zusammenfassen.

Damit die Versionen (tags) auch ins öffentliche Repository übertragen werden, dann muss zusätzlich der Befehl git push --tags verwendet werden. Mit dem Befehl git tag -d <tagname> können Tags wieder gelöscht und mit dem Befehl git tag -l alle Tags angezeigt werden.

git blame

Mit diesem Befehl kann herausgefunden werden, wer was an einer Datei geändert hat.

git rm

Das Löschen von Dateien im Repository.

Falls die Datei test nach dem git rm test doch wieder hergestellt werden soll, muss der Befehl git checkout HEAD -- test verwendet werden.

git mv

Eine Datei verschieben bzw. umbenennen.

git branch / git checkout / git merge / git log

Der Branch auf dem wir uns aktuell befinden, ist mit einem * markiert. Das ist zur Zeit der Branch master. Mit der Option -a werden auch die entfernten Branchen angezeigt.

Die Änderung aus dem Branch features-1 ist in den Branch master commited worden. Die neue Datei master.txt ist nur im Arbeitbereich vorhanden. Grundsätzlich sollte die Option --no-ff beim Merge verwendet werden. Diese Option erzwingt ein neues Commit-Objekt, auch wenn der Merge im fast-forward Modus durchgeführt wird. Damit können die Änderungen weiterhin auf den Feature-Branch sehen werden, im anderen Fall würden die Commits auf den Ziel-Branch verschoben.

Diese Option kann auch mit git config --global merge.ff "false" permanent eingestellt werden.

Ein größeres Beispiel zum parallelen Arbeiten mit Entwicklungzweigen ist im Beitrag Großes Beispiel mit Git und GitHub zu finden.

Die Option --pretty=oneline komprimiert die Daten eines Commits auf eine Zeile und die Option --graph zeigt die graphische Darstellung der Commits im Repository.

Spezielle Anwendungsfälle

Der Befehl git pull ist eine Zusammenfassung der Befehle git fetch und git merge. Eine Variante ist git pull --rebase als Kurzform von git fetch und git rebase.

Einen Branch aus einem entfernten Repository auschecken und mit der Option --track oder -t als einen Upstream konfiguriert, damit git pull den Branch auch im entfernten Repository synchronisieren kann.

Mit dem folgendem Befehl git cherry-pick können Code-Änderungen aus genau einem Commit in den aktuellen Branch übernommen werden. Dieses wird verwendet, wenn eine Änderung zwischen Branches ausgetauscht wird, die nicht zusammengeführt ( git merge) werden (z. B. Rückportierung einer Änderung in einen älteren Branch). Wird dieser Befehl zwischen Branches angewendet, die später zusammengeführt werden, so entsteht ein Konflikt.

Literaturempfehlung

Frank Rahn

Frank Rahn ist Softwarearchitekt. Er unterstützt bei der Konzeption von Softwarearchitekturen mit Java-Technologie. Folge Sie ihm auf Facebook, Twitter oder Google+.

Benötigen Sie Unterstützung? Kontaktieren Sie ihn.

Hat Ihnen dieser Beitrag gefallen? Wir würden uns über Ihren Kommentar freuen! Bitte verwenden Sie Ihren bürgerlichen Namen und eine E-Mail-Adresse mit Gravatar.

Letzte Artikel von Frank Rahn (Alle anzeigen)

1 Antwort

Trackbacks & Pingbacks

  1. […] empfehle den Beitrag Git mit GitHub, dort werden die Begriffe und Grundlagen von Git […]

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.