Letzte Änderung am 16. Mai 2023 by Christoph Jüngling
Vor einiger Zeit habe ich in diesem Blog recht viel über Mercurial (Kurzform: Hg) geschrieben. Ich war diesem gegenüber positiv eingestellt und sehe das auch immer noch genauso. Es ist relativ einfach zu erlernen, angenehm im täglichen Gebrauch und verfügt mit TortoiseHg über eine fantastische Workbench, die alles enthält, was Hg zu bieten hat. Auch wenn diese im ersten Moment erschlagend wirkt: Nachdem ich mich erstmal an alles gewöhnt hatte (und alles verstanden hatte), habe ich nur noch damit gearbeitet. Es ist wirklich nicht nur ein kleiner Wermutstropfen, dass TortoiseGit so etwas nicht enthält.
Doch Git hat in einigen Bereichen die Nase vorn. Da sich inzwischen wohl die gesamte Branche auf Git eingeschossen hat, wurde es Zeit, dass ich das ebenfalls lerne.
Gemeinsamkeiten
Netzwerke
Hg und Git sind beides sogenannte verteilte Quellcodeverwaltungen. Dies bedeutet, dass die gesamte Historie eines Projektes in einem Repository auf dem lokalen Rechner vorliegt (bei Git ist das nicht zwangsläufig der Fall, siehe “shallow clone”), man aber bei Bedarf durchaus auch mit entfernten Systemen kommunizieren kann. Das hat den Vorteil, dass jeder Commit, jedes Checkout und jede Suchoperation nur auf das lokale Dateisystem zugreifen muss.
Das gegenteilige Prinzip kommt bei Subversion (Kurzform: SVN) zum Einsatz. Dies ist eine zentralisierte Quellcodeverwaltung, daher benötigt jede Operation eine Verbindung zu einem Server.
Man stelle sich dieses Repository bitte nicht als einen weiteren Dienst unter Windows vor (auch wenn so etwas vom Prinzip her möglich wäre), sondern vielmehr als ein verstecktes Verzeichnis “gleich nebenan”. Nebenan bedeutet hier: Direkt im Arbeitsverzeichnis.
Bei Mercurial heißt dieses Verzeichnis .hg, bei Git naheliegenderweise .git. Der führende Punkt ist unter Windows ungewöhnlich, hat aber seinen Grund. Linux-Systeme betrachten alles, was mit einem Punkt beginnt, als “hidden”. Windows kennt dafür ein Dateiattribut, das prinzipbedingt auf alle Dateien angewendet werden kann, ohne sie umzubenennen. Wegen des Punktes also sind die Verzeichnisse .hg und .git auf Linuxsystemen zunächst nicht sichtbar. Unter Windows verwendet Git das Dateiattribut, um .git zu verbergen, so dass hier der gleiche Effekt erreicht wird. Mercurial trifft solche Vorkehrungen leider nicht, .hg ist also immer sichtbar. Selbstverständlich kann man auf beiden Systemen die versteckten Verzeichnisse auch sichtbar machen.
Fast alles, was in diesen beiden Verzeichnissen steht, sollte man tunlichst in Ruhe lassen, es sei denn, jemand wüsste ganz genau, zu welchem Zweck das da ist. Andernfalls wird sehr schnell alles in Unordnung gebracht und es gibt möglicherweise keinen anderen Weg heraus als alles zu löschen und von einem (hoffentlich vorhandenen) anderen Repository erneut zu klonen.
Im Arbeitsverzeichnis hingegen kann man sich in beiden Systemen nach Belieben austoben. Da der letzte Stand (hoffentlich) sicher in das lokale Repository committet wurde, kann der Entwickler jederzeit auf diesen Stand zurückgehen; es ist nichts verloren, das mühsam wiederhergestellt werden müsste. Auf der Konsole geht das jeweils mit einem kurzen Befehl:
git reset --hard HEAD hg update --clean
Die Befehle sind verschieden, das Ergebnis jedoch gleich: Alle lokal gemachten Änderungen werden auf den letzten Stand des aktuellen Branches aus dem Repository zurückgesetzt. Aber Vorsicht: Weg ist weg! Aber wenn man sich erst daran gewöhnt hat, so zu arbeiten, ist das wunderbar stressfrei.
Neueste Kommentare