eclipse - EGit HowTo An der HSR steht den Studierenden ein git Server für die Versionskontrolle zur Verfügung. Dieses HowTo fasst die notwendigen Informationen zur Verwendung dieses Dienstes in Verwendung mit eclipse EGit zusammen. Inhalt Allgemeines zu EGit EGit Dokumentation Benutzerangaben einstellen Nützliche Views Git Staging Git Repositories Properties Topologie Struktur eines git workspace Verfolgen von Änderungen Commit cycle Add to Index Ignore Stash cycle Branches Merge strategy Merge Rebase remote repository Erstellen Configure push Configure fetch Abgleich von Branches Merging References 20120921: Initiale Version Marcel Huber 20121021: Ergänzungen zu einzelnen Themen 20121022: Vervollständigung 20121023: Fertigstellung der Hauptthemen T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 1 von 10
Allgemeines zu EGit EGit Dokumentation Die Benutzerdokumentation wird mit dem EGit Plugin installiert und ist via Help Help Contents EGit Documentation aufzurufen. Benutzerangaben einstellen System- oder Projekt-Einstellungen, wie zum Beispiel user.email und user.name, können via Window Preferences Team Git Configuration eingestellt werden. Einstellungen können pro Benutzer und/oder pro Repository festgelegt werden. Identifying_yourself Nützliche Views Git Staging Die Git Staging View kann zur besseren Übersicht und zur einfacheren Handhabung geänderter Dateien nützlich sein. Sie kann im Menu Window Show View Other Git Git Staging geladen werden. Git_Staging_View Git Repositories Die Git Repositories View dient der Verwaltung lokaler git Repositories. In dieser View werden remote Repositories eingebunden, branches erstellt usw. Man findet sie unter Window Show View Other Git Git Repositories T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 2 von 10
Git_Repositories_View Properties Die Properties Ansicht ist eine allgemeine View, welche sich für die Kontrolle von Einstellungen bestens eignet. Window Show View Other General Properties Topologie Die folgende Grafik zeigt die topologischen Unterschiede von zentralen und verteilten Versionskontrollsystemen. T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 3 von 10
Clients von zentralisierten Systeme sind zum Zeitpunkt eines commit auf eine Verbindung zum zentralen Server angewiesen. Mit Clients dezentraler Systeme können alle Funktionen der Versionskontrolle, mit Ausnahme von repository Abgleichsfunktionen, genutzt werden. Zum Zeitpunkt des Abgleichs mit dem remote repository, push oder pull/fetch, kann erst festgestellt werden ob und wie sich beide Seiten verändert haben. Wenn der Ausgangspunkt unserer Änderungen nicht (mehr) identisch ist mit dem HEAD der Gegenstelle, müssen wir unsere Änderungen erst mit denen der Gegenstelle abgleichen. Struktur eines git workspace Die folgende Grafik zeigt die verschiedenen Bereiche einer Änderung vom workspace bis zum remote repository. Einzelne Bereiche werden nachfolgend mit Hilfe von Sequenzdiagrammen erläutert. Verfolgen von Änderungen T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 4 von 10
Commit cycle Dateien im workspace befinden sich typischerweise in einem der folgenden Zustände. Recording Changes Add to Index Solange wir Dateien nicht explizit mittels Team Add to Index vormerken, werden keine Änderungen aufgezeichnet. Ignore Soll eine Datei oder ein Verzeichnis von der Versionskontrolle ausgenommen werden, kann dies mittels Team Ignore vorgenommen werden. Überprüfen Sie den Inhalt der Datei.gitignore wenn Sie unsicher sind welche Dateien und Verzeichnisse ignoriert werden. Verzeichniseinträge enden üblicherweise mit einem slash / um sie von regulären Dateinamen zu unterscheiden. Beispiele: dir/ file *.class Track_Changes Stash cycle git bietet die Möglichkeit, Änderungen ohne Erzeugen eines commits zwischenzuspeichern. Damit können vorliegende Änderungen kurzzeitig zurückgestellt werden um beispielsweise auf einen anderen Branch zu wechseln oder das Programm im ursprünglichen Zustand nochmals genauer zu betrachten. T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 5 von 10
Das Kontextmenu zum Speichern respektive Wiederherstellen eines Stash findet sich in der Git Repositories View auf dem entsprechenden Repository. Vorhandene Stash Einträge sind in der Git Repositories View unter Stashed Changes finden. Branches Ein Branch ist im Prinzip nur ein Zeiger auf einen bestimmten commit, mit welchem man durch Traversieren entlang der Parents zur Gabelung vom Stamm findet. Ein Branch kann nicht nur auf einem logischen Namen, wie origin/master, sondern auf irgend einem existierenden commit basieren. Lokale Branches sind grundsätzlich gleichwertig wie remote Branches. Typischerweise leben lokale Branches nicht sehr lange; 1. ein lokaler Feature Branch wird erstellt 2. das Feature realisiert, getestet und committed 3. Änderungen des remote repository werden abgeholt (pull) hier kann es keine Konflikte geben, da wir auf dem lokalen master nichts geändert haben! 4. die Änderung werden auf den lokalen master Branch gemerged etwaige Konflikte lösen 5. der lokale Branch wird nach erfolgreichem Merge gelöscht 6. der master Branch wird zum remote repository gepusht Die Einträge in der Sektion Remote Tracking zeigen Branch Namen, welche im remote repository zu finden sind. Basierend auf einem dieser Branches kann dann ein lokaler Branch erstellt (checkout) werden. T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 6 von 10
Merge strategy git unterscheidet grundsätzlich zwei Arten um Änderungen zweier Zweige zusammenzuführen. Merge Die eine Art nennt sich Merge und erstellt aus den HEAD Versionen beider Äste ein neues commit Objekt mit den zusammengeführten Änderungen. Rebase Die zweite Art nennt sich Rebase, manchmal auch fast-forward genannt. Dabei wird die Gabelung des einen Astes an das Ende (HEAD) des anderen Astes verschoben. Dabei bleibt die Struktur der commits erhalten, inhaltlich kann es jedoch zu Anpassungen kommen. Die Merge Strategie verursacht im Allgemeinen weniger Probleme, hinterlässt dafür aber viele Gabelungen und Zusammenführungen in der Historie. In Verwendung mit gerrit ist diese Strategie jedoch unumgänglich, da sonst der Review-Prozess für jeden einzelnen commit durchgeführt werden muss. T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 7 von 10
Branching remote repository Der Ausdruck remote repository bezeichnet eine Verbindung unseres lokalen Repository zu einem Entfernten. Dabei spielt es keine Rolle, ob das remote Repository im eigenen Filesystem liegt oder über ein bestimmtes Protokoll eine Stelle im Netzwerk referenziert. Erstellen Unabhängig davon ob das Repository des vorliegenden Projekts von einem remote repository geklont wurde, können wir weitere remote repositories hinzufügen. Einstellungen lassen sich am einfachsten in der Git Repositories View tätigen, da diese Ansicht für diesen Zweck gut strukturiert ist und bestehende Einstellungen mit Hilfe der Properties View angesehen werden können. T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 8 von 10
Im Kontextmenu des Remotes Eintrages finden wir den Punkt Create Remote... über welchen wir das gewünschte remote repository anbinden können. Der Name des remote repository ist meist origin (Ursprung), kann aber grundsätzlich beliebig gewählt werden. Welche Richtung wir konfigurieren hängt davon ab, für welche Richtungen wir das entsprechende remote repository verwenden. In unserem Fall, wir wollen nur mit einem remote repository arbeiten, müssen wir beide Richtungen einstellen und fangen mit der voreingestellten Richtung an. Configure push Diese Richtung bestimmt, welche lokalen branches ins remote repository gelangen. Entweder kann man jeden einzelnen Branches definieren, welcher jeweils ins remote repository gepusht werden kann, oder man wählt die Voreinstellung, mit welcher der jeweils aktive Branch abgeglichen wird. Configure fetch Diese Einstellung bestimmt, welche Branches des remote repository in unser lokales repository gelangen. In den meisten Fällen ist die Voreinstellung passend, welche alle remote Branches in unser lokales repository lädt. Abgleich von Branches Nun müssen wir unserem lokalen master Branch noch mitteilen, welchem entfernten Branch er folgen soll. Dadurch wird ersichtlich, ob der lokale Branch dem remote Branch voraus eilt oder hinterher hinkt. Zuerst müssen wir jedoch den aktuellen Stand vom remote repository abholen und wählen dazu im Kontextmenu unseres Repository Fetch from Upstream. T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 9 von 10
Nun wählen wir im Kontextmenu des lokalen master Branches Configure Branch... und wählen als Gegenstück refs/remotes/origin/master. Damit sind wir nun bereit im Team zu arbeiten. Nach vollendeter Konfiguration beider Seiten ergibt sich das folgende Bild: Merging Das Merging mit EGit ist in weiten Teilen gleich wie bei anderen Versionskontrollsystemen. Der Unterschied liegt jedoch darin, dass wir bei Verwendung von git getätigte Änderungen jeweils erst mit Add to Index in den Staging Bereich eintragen müssen damit git diese als gemerged erkennt. Merging References Git_For_Eclipse_Users eclipse-egit wiki EGit-User_Guide egit-tutorial-for-beginners EGit-Tutorial-Lars-Vogel Tutorials der EclipseCon12 T +41 55 222 46 30 F +41 55 222 46 29 ifs@hsr.ch www.ifs.hsr.ch Seite 10 von 10