Versionsverwaltung mit Eclipse und Git

Kürzlich schrieb ich über Versionsverwaltung mit Eclipse und hatte mich für die Subversion-Software entschieden. Inzwischen habe ich jedoch herausgefunden, dass Git, Mercurial und andere “Distributed Version Control Systems” besser geeignet sind, um parallel mit mehreren Projektarchiven (repositories) zu arbeiten. Insbesondere Git zeichnet sich dadurch aus, dass es immer eine lokale Kopie des Archivs bereit hält. Da ich regelmäßig offline vom Notebook aus arbeite, ist diese Funktion für mich essentiell, da ich so zunächst meine Änderungen beim lokalen Archiv “einchecke” und dann, sobald eine Internetverbindung vorhanden ist, das lokale mit dem entfernten (remote) Verzeichnis synchronisiere (“push”).

Unter Eclipse funktioniert das ganze mit dem Plugin “EGit”.

Hilfreiche Links (englisch)

• Allgemeines EGit Tutorial
• Konfiguration mit GitHub als remote repository
• Konfiguration mit Assembla als remote repository
• Wer tiefer in die Materie einsteigen will, dem sei das freie Buch “Pro Git” von Scott Chacon empfohlen.

Hinweise zur Installation

• Aufgrund diverser Fehlermeldung bei der Verwendnung von EGit unter Ubuntu habe ich die aktuelle Version von Eclipse (“Juno”) manuell installiert, da der Ubuntu-Paketmanager bislang nur die ältere Version “Indigo” bereitstellt. Durch das viele Hin und Her bei der Installation und Einrichtung kann ich aber nicht mehr nachvollziehen, ob das tatsächlich der entscheinende Schritt war, um EGit fehlerfrei zum Laufen zu bringen.
• Zudem ist es aktuell anscheinend vorteilhaft, nicht den letzten “stable” Release (2.3.1) von EGit, sondern den “bleeding edge” Release (3.2) zu installieren. Zumindest verschwindet bei mir damit der Fehler “Invalid channel 117” beim Push zu Assembla.

Hinweise zur Benutzung:

• EGit verwendet anstelle des üblichen Begriffs “stage” den weniger verbreiteten Ausdruck “Index”. “Add to index” ist also äquivalent zur dem üblichen Ausdruck “stage file”.
• Allerdings werden sowieso standardmäßig alle “getrackten” Dateien in den “commit” mit einbezogen (git commit -a), so dass das “staging” eigentlich überflüssig wird (?).