Git
Einleitung
Git ist eine Versionsmanagement-Software, mit der in der Softwareentwicklung der Code einfach auf frühere Versionen zugegriffen werden kann und neue Versionen der Anwendung gespeichert werden können. Dabei ist auch Ziel, Entwickler unabhängig an verschiedenen Teilen der Anwendung mit einer minimalen Anzahl von Merge-Konflikten (unterschiedlichen Varianten von Code in der gleichen Version) arbeiten zu lassen.
Entwickelt wurde Git von Linus Torvalds ab 2005, da er die Effizienz der frei verfügbaren Versionsmanagement-Software für die Weiterentwicklung des Linux-Kernels als nicht ausreichend befand. Ein großer Unterschied von Git zu anderer Versionsmanagement-Software ist, dass Git alle Arbeitsschritte aller Entwickler in einer gemeinsam genutzten Baumstruktur zusammenfasst, von dem jeder Entwickler ein Klon für lokale Weiterentwicklung hat.
69% aller Projekte auf Open Hub werden mit Git gemanagt. Git ist ausreichend Leistungsstark für das Versionsmanagement ganzer Betriebssysteme; sowohl Linux als auch Windows verwenden Git.
Insgesamt ist Versionsmanagement ein zentrales Element moderner, kollaborativer Softwareentwicklung, auf das kaum verzichtet werden kann. Glücklicherweise reicht die Kenntnis einiger Basisfunktionen und Konzepte von Git für einen Einstieg in das Versionsmanagement aus, welche im folgenden vorgestellt werden.
Installation
Windows
Ein Installer für Windows wird auf der offiziellen Webseite von Git zur Verfügung gestellt.
Mac-OSX
Die Installation auf Mac/OSX erfolgt via Homebrew:
brew install git
Ubuntu Linux
Auf Ubuntu Linux wird git mit apt installiert:
sudo apt update sudo apt install git
Grundlagen
Alle Entwickler des Projektes haben eine lokale Kopie der gesamten Versionshistorie, an der sie Änderungen vornehmen können. Dabei kann die Versionshistorie entweder lokal gespeichert werden oder auf einem Online-Hoster wie GitHub.
verwaltet werden. Letzteres, das Online-Hosting von Git-Versionshistorien, ist natürlich unerlässlich bei Kollaboration übers Internet.
Ein Satz von zusammengehörigen Änderungen wird als Commit bezeichnet und mit einer passenden Nachricht versehen, beispielsweise "Alle Buttons blau gefärbt". Diese Commits können dann mit einem push in die in einem Repository gespeicherte globale Versionshistorie integriert werden. Dabei sollten folgende Leitgedanken berücksichtigt werden:
- Zusammengehörige Änderungen commiten
- Häufig commiten
- Nur abgeschlossene Änderungen commiten
- Vor dem Commit testen
- Prägnante Commitbeschreibungen
Falls dabei Commits von verschiedenen Entwicklern auf die selbe Datei fallen, können Merge-Konflikte auftreten. Ein Merge-Konflikt liegt dann vor, falls Änderungen nicht nur in der gleichen Datei, sondern auch in der gleichen Zeile vorliegen. Zur Auflösung von Merge-Konflikten gibt es Werkzeuge, gegebenenfalls kann aber manuelle Intervention nötig sein.
Von Bedeutung ist auch der Status des Entwicklers. Hat der Entwickler den Status Collaborator, so kann er seine lokalen Änderungen direkt auf das Repository pushen. Andernfalls muss der Entwickler einen pull request abgeben, woraufhin ein Collaborator die Änderungen entweder in das Repository integrieren oder verwerfen kann.
Ein weiteres, leistungsfähiges Werkzeug der Versionskontrolle ist das Speichern verschiedener Versionen einer Software als sogenannte Branches. Branches können unter anderem für Versionen für verschiedene Betriebssysteme oder für stabile oder experimentielle Versionen angelegt werden.
Zusätzlich können einzelne Commits mit einem benannten Tag versehen werden, auf das zu einem späteren Zeitpunkt einfach zugegriffen werden kann.
Verwendung
Repositories erzeugen
Neue Git-Repositories werden so erzeugt:
mkdir projekt && cd projekt git init
Soll statt dessen ein bereits vorhandenes Repository geklont werden, so ist folgendes einzugeben:
git clone ssh://nutzer@domain.com/repository.git
Anstelle von SSH kann auch HTTPS als Protokoll verwendet werden, je nachdem, wo das Repository liegt.
Lokale Änderungen
Das entweder lokal gespeicherte oder geklonte Repository kann jetzt lokal bearbeitet werden. Mit
git diff
werden alle Änderungen an lokalen Dateien seit dem letzten Commit angezeigt. Der folgende Befehl fügt dem nächsten Commit alle Änderungen inklusive neuer Dateien im aktuellen Verzeichnis hinzu:
git add .
Sind alle Änderungen erfolgt, kann commitet werden. Dies erfolgt durch die Eingabe von
git commit -am"Nachricht"
mit einer möglichst präzisen, aber kurzen Commit-Message. Sollen weitere Änderungen dem letzten Commit hinzugefügt werden, ist
git commit --amend
Waren die Änderungen nicht hilfreich, so können sie verworfen werden mit
git stash
Commitverlauf
Versionsmanagement benötigt effektiven Zugriff auf die Versionshistorie einer Software. Mit git log wird der Commitverlauf ausgegeben, gegebenenfalls beschränkt auf eine Anzahl zuückliegender Commits mit einem Parameter:
git log git log -n5
Der zweite Befehl zeigt nur die letzten fünf Commits an. Weiterhin kann die Historie nur einer bestimmten Datei angezeigt werden:
git -p DATEIPFAD
Möchte man wissen, wer an einer Datei gearbeitet hat, hilft blame weiter:
git blame DATEIPFAD
Branches und Tags
Mit Branches uns Tags kann einfach zwischen verschiedenen Versionen und Zwischenstufen einer Software gewechselt werden.
git branch -av git tag
Der erste Befehl zeigt alle Branches, der zweite alle Tags an. Der folgende Befehl erzeugt einen neuen Branch namens test aus dem aktuellen Stand der Versionshistorie:
git branch test
Soll statt dessen ein Branch gelöscht werden, so ist der Parameter -d zu übergeben:
git branch -d test
Zwischen Branches wird mit checkout gewechselt:
git checkout BRANCH
Analog dazu können Tags erzeugt, ausgewählt und gelöscht werden:
git tag TAGNAME git tag -d TAGNAME git checkout TAGNAME
Allgemein gilt, dass Branches für stark verschiedene Versionen verwendet werden wie beispielsweise eine Linux- und eine Windowsversion, Tags hingegen eher für kleine Änderungen wie Bugfixes und ähnliches.
Aktualisieren und Publizieren
Git Repositories werden entweder lokal abgelegt oder remote auf einem Server wie GitHub gespeichert. Die derzeit aktiven Remote-Verbindungen werden folgendermaßen angezeigt:
git remote -v
So werden die Daten einer Remoteverbindung namens REMOTE mit show ausgegeben:
git remote show REMOTE
Eine neue Remoteverbindung namens REMOTE mit der Ziel-URL als Parameter wird mit add eingerichtet:
git remote add REMOTE URL
Wenn ein anderer Entwickler Änderungen eines Branch BRANCH in das Projekt integriert hat, so können diese Änderungen mit pull in die eigene, lokale Kopie der Versionshistorie integriert werden:
git pull REMOTE BRANCH
Analog dazu werden mit push eigene Commits des bearbeiteten Branches hochgeladen:
>git push REMOTE BRANCH
Tags müssen seperat hochgeladen werden:
git push -tags
Soll eine Branch im remote Repository gelöscht werden, kann dies so erfolgen:
git branch -dr REMOTE/BRANCH
Merge und Rebase
Merge bezeichnet die Integration eines Branches in die eigene, lokale Entwicklungshistorie. Ein Rebase ist statt dessen die Integration der lokalen Entwicklungshistorie in einen anderen Branch.
git rebase BRANCH
Treten Konflikte auf, so kann das Rebase abgebrochen werden:
git rebase -abort
So können erst Merge-Konflikte aufgelöst werden, bevor das Rebase mit -continue fortgesetzt wird:
git rebase -continue
Wenn zwei Entwickler in ihren Commits an der gleichen Datei gearbeitet haben, so entsteht ein Merge-Konflikt. Diese können beispielsweise mit dem Git mergetool aufgelöst werden:
git mergetool
Wurden die Konflikte aufgelöst, so muss die entsprechende Datei wieder git hinzugefügt werden:
git add DATEI
Änderungen verwerfen
Für den Fall, dass die vorherigen Änderungen sich als nicht hilfreich erweisen, bietet Git zahlreiche Möglichkeiten, diese zu verwerfen.
git reset –hard HEAD
Obiger Befehl verwirft alle lokalen Änderungen seit dem Commmit HEAD. HEAD ist hierbei ein alphanumerischer Kennzeichner, wie angezeigt durch git log. Vorsicht: die verworfenen Änderungen können nicht wiederhergestellt werden!
Sollen statt dessen nur die lokalen Änderungen einer spezifischen Datei verworfen werden, kann checkout verwendet werden:
git checkout HEAD DATEI
Ausserdem können auch alle lokalen Änderungen mit einem neuen Commit verworfen werden:
git revert COMMIT
Glossar
Blame (hier: Verantwortung)
Mit dem Befehl Blame wird für jede Zeile einer Datei angezeigt, wer wann die letzte Veränderung daran vorgenommen hat.
Branch (Zweig)
Bei der Entwicklung einer Software kann es erforderlich sein, verschiedene Versionen in der Form von Branches parallel zu entwickeln und zur Verfügung zu stellen. Beispielsweise kann ein Branch zum sicheren Experimentieren mit neuen Komponenten angelegt werden (häufig dev genannt), oder es können parallel Versionen für Python2 und Python3 angelegt werden.
Checkout (etwa: Wechsel)
Der Befehl zum Wechsel auf einen anderen Branch. HEAD und Index werden dabei auf den gewählten Branch gesetzt.
Cherry-pick (etwa: Rosinen rauspicken)
Mit einem Cherry-pick wird ein spezifischer Commit eines Branches auf einen anderen Branch angewendet. Dies kann unter anderem zum Einbringen eines Commits in den Ziel-Branch genutzt werden, nachdem der Commit auf einen falschen Branch ausgeführt wurde.
Clean (sauber)
Ein Working Directory ist Clean, wenn keinerlei Abweichungen zum letzten Commit vorliegen, das heisst keine Dateien verändert wurden.
Clone (Klonen)
Der Befehl Clone erlaubt das Herunterladen eines gesamten Repositories auf einen Computer, auf dem ein Entwickler dann lokale Modifikationen vornehmen kann, die anschließend in das Master-Repository auf dem Server integriert werden.
Collaborator (Mitarbeiter)
Alle Entwickler eines Repositories, die über Lesund
Schreibrechte verfügen.
Commit (Übergabe)
Ein Commit speichert den aktuellen Stand des Working Directories, also die jüngst vorgenommenen Modifikationen, zusammen mit einer beschreibenden Nachricht und weiteren Metadaten wie Datum, Uhrzeit und Autor als den nächsten Arbeitsschritt in der Historie.
Contributor (Beitragender)
Ein Entwickler, dessen Pull Request in das Repository integriert wurde, der aber kein Collaborator ist.
Diff (Differenz)
Die Anzeige der Unterschiede zwischen zwei Dateien. Wird benutzt, um Bugs zwischen verschiedenen Commits aufzuspüren.
Forking (Gabelung)
Forking bezeichnet das Klonen eines Online-Repositories für das eigene Benutzerkonto. Damit können Entwickler unabhängig an einem Projekt arbeiten, ohne Teil der ursprünglichen Entwicklergruppe zu sein, beispielsweise um die Software für ein anderes Betriebssystem zu portieren.
HEAD (Kopf)
Ein Zeiger auf den aktuellen Commit des derzeitigen Branches. Üblicherweise der jüngste Commit des Branches, kann aber mit Git-Befehlen versetzt werden, um auf ältere Commits zuzugreifen.
Index
Index bezeichnet die Vorbereitung des Working Directory vor einem Commit. Dabei wird ausgewählt, welche geänderten oder neu erstellten Dateien dem Commit hinzugefügt werden.
Issue (Angelegenheit)
Finden Nutzer eines Repositories einen Bug oder wünschen eine Erweiterung der Software, können sie auf GitHub eine Issue eingeben, die dann von den Entwicklern entweder bearbeitet oder zurückgewiesen wird.
Log
Log dient der Darstellung der Commit-Historie des aktuellen Branches.
Markdown
Markdown ist eine einfache Formatierungssprache für Textdateien, mit der häufig README-Dateien formatiert werden.
Merge (Vereinigung)
Im üblichen Arbeitszyklus wird zuerst ein Pull ausgeführt, damit der lokale Klon des Repositories auf dem neusten Stand ist. Anschliessend werden lokale Modifikationen vorgenommen, die dann anschliessend mit einem Commit und Push in das Online-Repository integriert werden. Dabei wird ein Merge durchgeführt - die neuen Programmteile werden integriert. Wenn allerdings zwei Entwickler an den gleichen Programmteilen gleichzeitig lokal gearbeitet haben, kann dabei ein Merge-Konflikt auftreten, da das Online-Repository nicht weiß, welche Teile übernommen werden sollen. Üblicherweise müssen derartige Merge-Konflikte manuell aufgelöst werden.
Parent (Elter)
Parent ist eine Liste mit allen logischen Vorgängern eines Commits.
Pull (Ziehen)
Durch Pull werden alle Änderungen, die im Master-Repository von anderen Entwicklern vorgenommen wurden, aber nicht im lokalen Klon enthalten sind, auf das lokale Repository angewendet.
Push (Stoßen)
Mit einem Push werden alle zuletzt vorgenommenen Commits dem Repository des Projektes hinzugefügt, entweder auf einem Server wie beispielsweise GitHub oder in einem lokalen Repository auf der Festplatte.
Rebase
Bei einem Rebase werden die Änderungen eines Branches auf einen anderen Branch angewendet, beispielsweise von einem experimentiellem Branch auf Master. Anschließend kann der experimentielle Branch in Master gemerged werden, wodurch im Gegensatz zu einem direkten Merge eine lineare Entwicklungshistorie ensteht.
Repository (Ablage)
Ein Repository beinhaltet ein Projekt mitsamt seiner Entwicklungshistorie. Das heisst, alle Zwischenschritte (in Form von Commits) der Software können wiederhergestellt oder betrachtet werden. Im Fall von Git wird unterschieden zwischen einem meißt online verfügbaren Master-Repository und lokalen Klonen bei allen beteiligten Entwicklern, die so unabhängig voneinander an dem Projekt arbeiten können.
Resolve (Auflösen)
Resolve bezeichnet das manuelle Auflösen von Merge-Konflikten.
Rewind (Zurückspulen)
Mit einem Rewind wird der HEAD auf einen früheren Commit zurückgesetzt und die Arbeit bis zu diesem Commit verworfen.
SHA-1
Mit SHA (Secure Hash Algorithmus) werden Prüfsummen für digitale Informationen erstellt. Die Prüfsumme hat immer 40 hexadezimale Zeichen. In Git wird SHA verwendet, um Commits zu benennen. Somit kann die Validität eines Commits anhand seines Namens überprüft werden.
Tag (Markierung)
Tags sind vom Entwickler angelegte Markierungen, auf die einfach zugegriffen werden kann. Dadurch wird die Verwaltung der komplexen Entwicklungshistorie eines Projektes vereinfacht. Tags werden dazu mit Bezeichnern versehen, wie beispielsweise v1.01 oder Django statt Flask.
Upstream (Flussauf)
Synonym für das Master-Repository. Der lokale Klon eines Repositories wird auch Downstream genannt.
Versionskontrollsystem (Concurrent Version System, CVS)
Versionskontrollsysteme dienen der Verwaltung verschiedener Versionen einer Software. Bekannte CVS neben Git sind Subversion und CVS. Ein CVS speichert die gesamte Entwicklungshistorie einer Software und ermöglicht die Zusammenarbeitet mehrerer Entwickler in kollaborativen Projekten.
Working Tree (Arbeitsverzeichnis)
Der Working Tree beinhaltet alle Dateien des Projektes im derzeitigen Zustand und kann bei Bedarf vom CVS auf einen früheren Zustand zurückgesetzt werden.