Git-Tutorial

Git ist wie SVN oder CVS ein Tool zur Versionsverwaltung von Dateien. Im Gegensatz zu diesen ist es jedoch ein Verteiltes System, heißt also, man kann auch offline Versionierung betreiben.

Für mehr Details verweise ich mal auf Wikipedia:

Git ist ein verteiltes Versionsverwaltungssystem, das sich in einigen Eigenschaften von traditionellen Versionskontrollsystemen unterscheidet:

  • Nicht-lineare Entwicklung: Sowohl das Erstellen neuer Entwicklungszweige (branching) als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind integraler Bestandteil der Arbeit mit Git und sind fest in die Git-Werkzeuge eingebaut.[3] Git enthält Programme, mit deren Hilfe sich die nicht-lineare Geschichte eines Projektes einfach visualisieren lässt, und mit deren Hilfe man in dieser Geschichte navigieren kann.
  • Kein zentraler Server: Jeder Benutzer besitzt eine lokale Kopie des gesamten Repositories, inklusive der Versionsgeschichte (history). So können die meisten Aktionen lokal und ohne Netzwerkzugriff ausgeführt werden. Es wird nicht zwischen lokalen Entwicklungszweigen und Entwicklungszweigen entfernter Repositories unterschieden. Obwohl es keinen technischen Unterschied zwischen verschiedenen Repositories gibt, gibt es in der Regel einen gesellschaftlichen Unterschied: Die Kopie, auf die von einer Projekt-Homepage aus verwiesen wird, gilt häufig als das „offizielle Repository”.
  • Datentransfer zwischen Repositories: Daten können mit einer Reihe verschiedener Protokolle zwischen Repositories übertragen werden. Git besitzt ein eigenes Protokoll, das den TCP-Port 9418 nutzt. Ebenso kann der Transfer über SSH oder (weniger effizient) über HTTP, HTTPS, FTP oder rsync erfolgen.[4] Die Übertragung in das „offizielle Repository“ eines Projekts erfolgt häufig in Form von Patches, die via E-Mail an den Entwickler oder eine Entwicklungs-Mailing-Liste geschickt werden.[5]
  • Kryptographische Sicherheit der Projektgeschichte: Die Geschichte eines Projektes wird so gespeichert, dass der Name einer beliebigen Revision (commit) auf der vollständigen Geschichte basiert, die zu dieser Revision geführt hat. Dadurch ist es nicht möglich, die Versionsgeschichte nachträglich zu manipulieren, ohne dass sich der Name der Revision ändert. Einzelne Revisionen können zusätzlich markiert und mit GPG digital signiert werden (tagging), beispielsweise um den Zustand zum Zeitpunkt der Veröffentlichung einer neuen Version der Software zu kennzeichnen.
  • Verzeichnisbasiertes Verständnis: Im Gegensatz zu traditionellen Versionskontrollsystemen wie SCCS, RCS und CVS arbeitet Git nicht auf einzelnen Dateien, sondern auf Verzeichnissen und Hierarchien von Verzeichnissen.
  • Säubern des Repositories: Die Daten gelöschter und zurückgenommener Aktionen und Entwicklungszweige bleiben vorhanden (und können wiederhergestellt werden), bis sie explizit gelöscht werden.

Arbeiten mit der Kommandozeile

Als allererstes sollte man dem System mitteilen wer man ist, bzw. unter welchem Synonym man assoziiert werden möchte:

$ git config –global user.name „Max Mustermann“
$ git config –global user.email max@muster.man

Initialisieren, bzw. ‚herunterladen‘ des aktuellen Projektes (hier mapnex) funktioniert dann mit:

$ git clone ssh://git@korsika.informatik.uni-kiel.de/mapnex „mapnex“

Notiz zum SSH-Key: In unserer Gruppe ist es vermehrt aufgetreten, dass die git-Autorisierung mittels des SSH-keys nicht geklappt hat. Geholfen hat unter Anderem, den Key nach seinem default-Namen zu benennen, dass heißt den Key umzubenennen nach „id_rsa“ bzw. „id_rsa.pub“, sofern dieser nicht bereits existiert.
Sollte immernoch nach einem Passwort gefragt werden, hat bei uns auch geholfen, vorher einmal per ’ssh -i /path/to/private-ssh-key git@korsika.informatik.uni-kiel.de‘ die existenz des Keys zu testen.

Damit wird automatisch ein Ordner „mapnex“ angelegt, der eine komplette Kopie des Repositories enthält und zudem einen Verweis unter ‚origin‘ auf das Ursprungs-repo.
Aktualisieren vom Server kann man nun mit:

$ git pull origin

bzw. wenn man nur hineinschnuppern möchte, was dort passiert ist, ohne die lokal zu mergen:

$ git fetch origin

Wenn man nun lokal Dateien geändert oder erstellt hat, kann man diese Änderungen mit:

$ git status

betrachen.

So stellt man Änderungen oder auch neue Dateien auf die Liste für das nächste commit:

$ git add path/to/new/file

(Im Gegensatz zu svn ruft man also add während der Projektentwicklung mehrmals für dieselbe Datei auf.)

Ein commit aller per add hinzugefügten Dateien wird mit der folgenden Zeile initiiert:

$ git commit -m „tolle Änderungen durchgeführt“

Der Parameter ‚m‘ gibt hierbei die Commit-Nachricht an. Fehlt der Parameter, wird ein Editor gestartet.

Man kann ein Verhalten wie bei svn bewirken, also beim commit automatisch alle veränderten Dateien hinzu fügen, bzw. lokal gelöschte Dateien auch im lokalen repo löschen.
Dazu benutzt man den Parameter ‚a‘, also z.B.:

$ git commit -a -m „tolle Änderungen durchgeführt“

Nun sind die Änderungen jedoch erst lokal. Um diese auch in das Haupt-repo zu bekomme genügt ein

$ git push origin

Alternativ kann man mit git-patch auch Textbasierte Patches erstellen, diese habe ich jedoch noch nie benutzt.

Generell kann man zu jedem Zeitpunkt mit

$ git whatchanged

nachsehen, was man alles verändert hat.

Um eine Historie all dieser Commits zu betrachten, kann

$ git log

herangezogen werden.

Generell kann mit

$ git help befehl

genaueres zu dem jeweiligen Befehl durchgelesen werden.
Zum Beispiel

$ git help add
$ git help tag

Arbeiten mit GUI

Fast all dies funktioniert fast genauso komfortabel mit der von git mitgebrachten GUI.

git gui

Aufrufen tut man diese mit

$ git gui

Diese zeigt dann an, wo sich etwas geändert hat, und bietet an, diese teilweise oder komplett bereitzustellen (‚alles bereitstellen‘), danach zu commiten (‚eintragen‘) und auch über die Oberfläche direkt zu einem beliebigen Remote-Repo zu pushen (‚versenden‘).

gitk

gitk ist ein in git gui integriertes Tool, um die Historie (git log) grafisch anzuzeigen.

Branch und Merge

Man kann nun, wie in jedem vernünftigen Versionierungstool mehrere Zweige der Entwicklung anlegen.
Hierzu nutze

$ git branch experimental

mit

$ git branch
experimental
* master

kann man dann sehen, welche Zweige (Branches) es momentan so gibt. Der Stern zeigt dabei den aktiven an.
Auch in

$ git status

wird der aktuelle Zweig vermerkt.

Um zwischen den Zweigen hin und her zu wechseln nutzt man

$ git checkout experimental

bzw. um nachher wieder zurück zu wechseln,

$ git checkout master

Merging

Um die Unterschiede zu einem anderen Zweig heraus zu finden, nutzt man

$ git diff

bzw. hier:

$ git diff experimental

Zum zusammenzufügen zweier Zweige nutzt man den merge-befehl

$ git merge experimental

Danach kann (und sollte) man den damit inaktiv gewordenen Zweig wieder löschen

$ git branch -d experimental

Wenn der Zweig ohne merging wieder gelöscht werden soll, so muss anstelle des “‘-d“‘ ein “‘-D“‘ verwendet werden.

All dies ist natürlich auch über die Oberfläche (git gui) bequem zu erledigen. Die erforderlichen Optionen findet man im Menüpunkt “Zweig“.

Ein Gedanke zu „Git-Tutorial“

Schreibe einen Kommentar

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